Becoming a Technical Reference on the Team

During my years at Softcraft, engineers gradually began involving me in architecture discussions, difficult bugs, code reviews, and production problems. At first, I thought being a technical reference meant having fast answers. I put pressure on myself to remember the framework behavior, know the business rule or propose the correct design immediately. That didn’t work very well with larger systems. The problems crossed too many areas for one person to know everything, so I started helping the team investigate the uncertainty instead of trying to hide it with a quick answer.

Starting With the Problem

An engineer once brought me a backend problem that appeared to require a new asynchronous service. We already had a rough design in front of us, so it would have been easy to start debating queues and workers. Instead, we traced the current flow and found a dependency with unpredictable latency holding the user-facing request open. That changed the discussion. We could evaluate which part needed to become asynchronous, what state the user needed to see and how recovery should work. The queue became one part of a smaller design based on the problem we had found.

We drew the current sequence and marked the part the user needed immediately. Some validation still belonged in the request, while the slower external work could continue after the operation had been accepted. That gave the engineer a smaller design to implement and gave us specific cases to review later. If we had started with “new asynchronous service,” we probably would have distributed more of the workflow than the problem required.

Saying “I Don’t Know Yet”

Some questions genuinely required investigation. Saying “I don’t know yet” was uncomfortable at first. I worried it would sound unprepared. What helped was adding, “but here is what I’d verify.” We might inspect production behavior, create a small test, read the dependency’s documentation, or involve someone with more context in that area. Making the reasoning visible kept the trust and made it easier for other engineers to contribute. A confident answer can end a discussion too early, while a clear uncertainty gives the team something useful to investigate. When someone asked how to implement a change, giving a direct answer was often the fastest way to unblock the immediate task. Explaining the constraint took a little longer, but it was more valuable for the next task. “Use asynchronous processing” is an instruction. “This operation shouldn’t fail because one external service is temporarily unavailable” is a criterion. The criterion helps an engineer evaluate other solutions and make a new decision later.

I still gave direct answers when the question was simple or the team needed to recover an incident quickly. Not every conversation needed an investigation. The change was that I became more aware of when I was giving a fact, when I was sharing a preference and when I was making a guess based on incomplete context. That made it easier for the other person to challenge the answer without feeling like they were challenging my role on the team.

I started trying to share the reason behind recommendations: the business risk, production history, ownership boundary, or maintenance cost that made one option more appropriate. That context helped decisions continue without me.

I also wrote down decisions that kept returning in reviews. We had repeated discussions around integration retries, module boundaries and deployment requirements. A short record of what we had chosen and why allowed another engineer to continue the conversation without waiting for me to remember the history. The documentation didn’t replace discussion, but it reduced the number of questions that depended on one person being available.

Avoiding a Bottleneck

There was also a downside when too many reviews or production questions started waiting for the same person. I didn’t want being useful to turn into another queue for the team, so I documented repeated decisions and involved other engineers in areas where they could build more context. I still needed technical experience, of course, but I became more comfortable saying that I didn’t know something yet. Sometimes I knew the answer. Other times we needed a measurement, a small test or a person who understood that part of the system better. Those conversations felt much more honest than trying to respond immediately to everything.