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 some pressure on myself to respond immediately when someone asked a question. When someone asked a question, I wanted to know the framework behavior, remember the business rule, or propose the correct design immediately. That didn’t work very well with larger systems. The systems were too large and the problems crossed too many areas for one person to know everything. I needed to help the team move from uncertainty to a decision we could explain and validate.

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 of starting with the architecture, we traced why the current flow was failing. The issue wasn’t simply that the work took time. It was that one dependency had unpredictable latency and the user-facing request was waiting for it. That distinction changed the discussion. We could evaluate which part needed to become asynchronous, what state the user needed to see, and how recovery should work. “Add a queue” was no longer the solution. It was one tool inside a clearer design. The difficult part wasn’t knowing the pattern. It was understanding the actual problem.

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. In practice, this didn’t reduce trust. It made the reasoning visible. It also made it easier for other engineers to contribute. A confident answer can end a discussion too early. 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 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.

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.