Episode 6: Leading Without Becoming a Manager: Becoming the Person People Come To

Jona Obrador • August 18, 2026

Every engineering team eventually develops one of these engineers. The one somebody messages when production behaves strangely, or when nobody remembers why a system works the way it does. They tend to know which service, log, ticket, or old pull request holds the answer.


They are often not the most senior person on the team, and they certainly do not know everything. What they have is trust. Nobody gets there quickly. It comes from reliability, follow-through, and years of paying attention to problems as they surface.


In Episode 5, we looked at how the strongest engineers multiply their impact by sharing what they know instead of gatekeeping it, through documentation and code reviews that teach rather than only correct. The same principle applies to trust.

Trust Becomes a Form of Technical Influence

Trust Becomes a Form of Technical Influence

Technical leadership starts when people trust an engineer's judgment, which usually happens well before anyone hands over authority.


That trust changes how a team works. People get involved earlier, ask for a perspective before making a risky decision, and bring ambiguous problems over because they expect help finding a path forward. They also believe that a promise to look into something means the thing will actually get looked into.

Technical leadership starts when people trust an engineer's judgment, which usually happens well before anyone hands over authority.


That trust changes how a team works. People get involved earlier, ask for a perspective before making a risky decision, and bring ambiguous problems over because they expect help finding a path forward. They also believe that a promise to look into something means the thing will actually get looked into.

No title produces that. It has to be earned. And most of the time, it comes from many small interactions rather than one impressive technical achievement.

No title produces that. It has to be earned. And most of the time, it comes from many small interactions rather than one impressive technical achievement.

Why: Teams Need Reliable Points of Reference

Software systems accumulate history. Old design decisions, workarounds, customer-specific behavior, and dependencies that exist because of a call somebody made three years ago. Documentation helps and never captures all of it, so teams end up relying on people who hold enough context to connect the pieces quickly.


Software systems accumulate history. Old design decisions, workarounds, customer-specific behavior, and dependencies that exist because of a call somebody made three years ago. Documentation helps and never captures all of it, so teams end up relying on people who hold enough context to connect the pieces quickly.


Institutional knowledge by itself does not create trust. Plenty of engineers know a lot. The difference shows up in what happens when someone asks them for help and whether the problem is easier for the next person afterward.

Why: Teams Need Reliable Points of Reference

Each of those saves time this week and costs the team next quarter. The most valuable output of technical leadership is sometimes not code at all. It can be the context behind a decision, or an engineer who will not need help with the same problem next time.

Institutional knowledge by itself does not create trust. Plenty of engineers know a lot. The difference shows up in what happens when someone asks them for help and whether the problem is easier for the next person afterward.


Trust grows when people repeatedly experience the same thing:

“When this person gets involved, things move forward.”

Trust grows when people repeatedly experience the same thing:

“When this person gets involved, things move forward.”

If you need more time, communicate what you have learned so far. People do not expect technical leaders to know everything. They expect them to be dependable. One of the most trust-building sentences in engineering is "I don't know yet, but I'll find out," provided the engineer actually does.


Reliability compounds. One resolved issue does not make someone trusted. Dozens of small moments of consistent follow-through add up to a reputation.

How: Become Reliable Before Trying to Become Influential

How: Become Reliable Before Trying to Become Influential

Reliability sounds simple, but it is probably one of the most underrated leadership traits in engineering.


A promise to investigate something should end in an investigation. A promised update should arrive. When the answer is not there yet, saying so beats going quiet, and sharing partial findings beats waiting until everything is resolved.


If you need more time, communicate what you have learned so far. People do not expect technical leaders to know everything. They expect them to be dependable. One of the most trust-building sentences in engineering is "I don't know yet, but I'll find out," provided the engineer actually does.

Reliability sounds simple, but it is probably one of the most underrated leadership traits in engineering.


A promise to investigate something should end in an investigation. A promised update should arrive. When the answer is not there yet, saying so beats going quiet, and sharing partial findings beats waiting until everything is resolved.


Reliability compounds. One resolved issue does not make someone trusted. Dozens of small moments of consistent follow-through add up to a reputation.

If you need more time, communicate what you have learned so far. People do not expect technical leaders to know everything. They expect them to be dependable. One of the most trust-building sentences in engineering is "I don't know yet, but I'll find out," provided the engineer actually does.


Reliability compounds. One resolved issue does not make someone trusted. Dozens of small moments of consistent follow-through add up to a reputation.

Make Your Work Visible

Technical leadership is sometimes confused with having the final answer. It sits closer to caring more about the best answer than about whose answer it was.


Some of the most respected engineers have a habit that shows up surprisingly rarely. When presented with better information, they say, "Good point, let's go with that," and move on. There is no drawn-out defense of the original position.

That willingness usually earns more credibility than winning the point would have. Teams read it as a signal that the engineer evaluates ideas honestly, which makes their agreement worth more when it does come.

There is a difference between doing valuable work and making the value of that work accessible to the team. 



Technical leaders usually operate across several areas. They investigate recurring problems, notice patterns across projects, clarify architecture, and help engineers understand how their work interacts. When that thinking stays in one person's head, the team benefits only indirectly.


Make it visible. Sharing an investigation, explaining the reasoning behind a decision, summarizing what an incident taught, or linking related tickets all give other engineers enough context to follow the same path.

There is a difference between doing valuable work and making the value of that work accessible to the team. 

Technical leaders usually operate across several areas. They investigate recurring problems, notice patterns across projects, clarify architecture, and help engineers understand how their work interacts. When that thinking stays in one person's head, the team benefits only indirectly.

Make Your Work Visible

Visibility is not about self-promotion. It is about making useful context available rather than demonstrating how much someone knows.


The goal is not:

“Everyone should see how much I know.”


The goal is:

“Everyone should have access to what I learned.”

Make it visible. Sharing an investigation, explaining the reasoning behind a decision, summarizing what an incident taught, or linking related tickets all give other engineers enough context to follow the same path.


Visibility is not about self-promotion. It is about making useful context available rather than demonstrating how much someone knows.


The goal is not:

“Everyone should see how much I know.”



The goal is:

“Everyone should have access to what I learned.”

Learn Where to Look

Learn Where to Look

One misconception about experienced engineers is that they remember everything — most do not.


They simply become very good at knowing where information might exist. They know which logs are worth reading, which repository probably holds the implementation, which teammate worked on the feature, and which old ticket explains the strange behavior. They also know which documentation to trust and which assumptions are worth questioning.

One misconception about experienced engineers is that they remember everything — most do not.


They simply become very good at knowing where information might exist. They know which logs are worth reading, which repository probably holds the implementation, which teammate worked on the feature, and which old ticket explains the strange behavior. They also know which documentation to trust and which assumptions are worth questioning.

The skill develops through curiosity. Understanding why something broke matters more than applying the immediate fix, and tracing unfamiliar code back to its origin extends the mental map a little further each time. When a colleague explains a historical decision, the context around it is usually the part worth keeping.

The skill develops through curiosity. Understanding why something broke matters more than applying the immediate fix, and tracing unfamiliar code back to its origin extends the mental map a little further each time. When a colleague explains a historical decision, the context around it is usually the part worth keeping.

Build Institutional Knowledge Without Becoming a Bottleneck

There is a danger here. Becoming the person everyone comes to feels good, but it can quietly work against and become unhealthy for the team. If every question requires one specific engineer, the knowledge has not scaled.


Episode 5 covered the better pattern. People come with a problem, it gets solved, and then something changes so they will not need the same help next time. That might mean documenting the answer, walking them through how the investigation worked, pointing them to someone with deeper knowledge of that area, or fixing the confusing part of the system that generated the question in the first place.

Experienced engineers tend to become the default owners of difficult problems. Again, this feels efficient. But if we always take the hardest work, nobody else gets experience solving it.


Episode 2 covered the alternative, handling over ownership while staying available. That means letting another engineer lead an investigation with support rather than running it, giving someone a design proposal to own and reviewing their thinking, or bringing a less experienced engineer into a debugging session.

Build Institutional Knowledge Without Becoming a Bottleneck

Trust Is Built in Small Moments

Trust Is Built in Small Moments

Technical leadership is often imagined as something that shows up during major architectural decisions or critical production incidents. Those moments matter, and trust usually develops somewhere much less dramatic:


  • Answering a question thoroughly instead of quickly
  • Following up after a meeting
  • Remembering an unresolved issue everyone else forgot
  • Helping someone debug without taking over the keyboard
  • Admitting a mistake
  • Giving credit when someone else solved the problem
  • Sharing context before someone has to ask.

Individually these things feel small. Together, they build a reputation, and eventually people start coming to you because they trust you will help them find an answer. Not because you have all the answers. But because they trust that you will help them find one. In engineering teams, that kind of trust carries further than authority does.


At ATSOURCE, we build NetSuite teams where engineers earn that trust and pass on what they know. Let's talk about what that looks like for your organization.

Jona Obrador Senior Netsuite Developer

Meet the Author

Jona has over a decade of experience in SuiteCloud Development on the NetSuite platform. She specializes in implementing advanced solutions and has led teams in creating high-quality software. Jona holds multiple certifications and has been recognized with awards like the Summit Award and Quality Champion Award.

Tags

Accelerate ERP Success with Expert Solutions

Ready to put what you've learned into practice? ATSOURCE delivers both the specialized talent and comprehensive NetSuite support you need to turn strategy into results.‍Connect with our experts today and move from planning to performance.

Purple chat bubbles with check and X icons above a lightbulb on a white platform

Episode 5: Leading Without Becoming a Manager: Making Other Engineers Better

By Jona Obrador • August 12, 2026
Senior engineers add the most value by making teams more capable. How NetSuite engineers share knowledge instead of becoming a bottleneck.
Two chat bubbles with check and X icons above a lightbulb on a white pedestal, on a purple background

Episode 4: Leading Without Becoming a Manager: Disagreeing Professionally

By Jona Obrador • August 4, 2026
How strong NetSuite engineers challenge ideas without damaging relationships, and turn technical disagreement into better team decisions.
Purple code window with magnifying glass, gear, and alert light on a pedestal

Episode 3: Leading Without Becoming a Manager: Raising Standards Without Becoming the Code Police

By Jona Obrador • July 29, 2026
Learn how senior NetSuite engineers raise code quality through shared standards, selective feedback, and culture, not control.