For the first several years of my career, I was used to being the person with the answer. Not always the best answer — I got things wrong plenty — but when a technical question came up, my instinct was to engage with it directly. To think through it, form a view, and advocate for that view. That’s what good engineers do.
When I moved into management and eventually into leading teams of teams, I had to confront something I hadn’t fully anticipated: there were rooms I was walking into where I was genuinely not the most technically knowledgeable person. Not by a little — by a lot. My engineers had spent the last three years doing the work I used to do, which means they’d gone deeper on the specifics than I had. And yet, in those rooms, people were still looking to me for something. I just had to figure out what that something was.
The trap of false contribution
The failure mode I’ve seen most often in technical leaders who used to be strong ICs is what I’d call false contribution. You’re in an architectural review and you don’t fully understand the nuance of the decision at hand, but the silence feels uncomfortable, so you ask a question that sounds insightful but is really just filling space. Or you anchor on the one detail you do understand and advocate for it more forcefully than the evidence warrants because it’s the only ground you feel solid on.
I’ve done both of these things. The engineers in the room can tell. They’re polite about it, but they can tell, and what it does is subtly undermine the credibility you actually need — the credibility to say “I don’t know enough about this specific implementation to have an opinion, so I’m going to trust your judgment” and have people believe that’s a considered position rather than a cop-out.
What I actually contribute in those rooms
Over time, I’ve gotten clearer about what I bring to architectural discussions versus what I deliberately stay out of.
What I try to contribute: the business and customer context that may not be fully visible to the engineers closest to the implementation. The longer-term trajectory of where the system needs to go, based on things I know about the roadmap or the direction of the organisation. The risk framing — not the technical risk specifically, but the question of whether the team has pressure-tested the failure modes and thought through the scenarios that would make this decision look bad in two years. And the process: making sure the right people are in the room, that dissenting views are actually heard, and that we’re making a real decision rather than rubber-stamping what the most senior engineer advocates for.
What I deliberately stay out of: the specific implementation choices where my knowledge is six months or two years out of date. The comparative evaluation of technical approaches I haven’t worked with hands-on. Any position I’ve formed in the first five minutes of a conversation on a topic I haven’t been living with.
That second list is harder than it sounds. The instinct to engage is strong, especially when you have a view. I’ve had to develop a specific practice of asking myself, before I speak: does my input here actually make this decision better, or does it just satisfy my need to feel like I contributed?
The question I find most useful
The single most useful thing I’ve found I can contribute in architectural discussions is a version of this: “Walk me through what this decision looks like if the assumption that seems most load-bearing turns out to be wrong.” Not because I’m trying to be difficult, but because that question often hasn’t been asked, and the answer usually reveals something important.
It’s not a deeply technical question. It doesn’t require me to understand the implementation details. But it moves the conversation from “here’s the design” to “here’s how the design handles adversity,” which is almost always where the interesting risk lives.
The transition nobody talks about
The shift from “I know the right answer” to “I know how to get to the right answer” is one of the real transitions in moving from senior IC to engineering leader. It doesn’t happen automatically when your title changes. It requires you to consciously redefine what contribution looks like in your new role.
That redefinition is uncomfortable, especially early. There’s a grief to it — not a dramatic grief, but a real one — that comes from letting go of the identity of being the technical expert and replacing it with something that’s harder to immediately demonstrate. The engineers who do this well are the ones who accept the discomfort rather than try to shortcut it by pretending they’re still the expert.
The goal isn’t to become technically ignorant — staying technically curious matters, and I try hard to stay connected to the work my teams are doing. But there’s a difference between staying informed and needing to be the one with the answer. The sooner you make peace with that difference, the better the decisions your teams will make.