Last week I walked into a manager’s office just to say hi and good morning.
No agenda. No meeting on the calendar. Just a check-in, the kind of visit that starts casual and often ends up going deeper than intended.
This manager told me, almost in passing, that she was going to miss me when I left for an upcoming role. Not just our working relationship, but me specifically because I always seemed to have the right technical context when she needed it. Without that (and without me) she was worried she’d flounder. That she’d accidentally lead her team in the wrong direction or fail to give the more inexperienced people on her team the guidance they actually needed.
I’ve been in that exact headspace before. The internal spiral of what if I’m not what this team actually needs? Not just about technical expertise, but about tenure and context and age and all of the layers that stack up when the people you’re leading have been doing this longer, know the history you haven’t lived yet, and have expertise you’re still building toward.
All three of those things were true for me too at various points, especially after role transitions. They are true for her too and probably true for you at some point in your development path.
What I told her is something I had to learn for myself the slow way, and something I now believe enough to say out loud:
The most valuable thing you can bring to a room full of people who know more than you isn’t answers, it’s questions.
The right questions, asked at the right moments, do more work than any answers you could give a team.
Here’s what I mean. The reason “asking the right questions” sounds like an obvious answer is that most of the time it’s treated like a placeholder. Vague, deferential questions that signal you want someone else to do the thinking for you don’t move teams and projects forward. What moves everyone forward is a specific, action-oriented kind of question, one our team is often too close to the work to ask themselves.
The questions I actually walked through with the manager I mentioned were:
✅ “Where does this fall in our priorities right now — and does anything need to shift?”
This is the question only a manager can really own. Your team knows what they’re working on. They often don’t know whether the relative priority of that work has changed based on things you’ve heard in other rooms. Asking explicitly, on a regular cadence and not just when something breaks, keeps priorities from going stale without anyone noticing.
✅ “What dependencies, roadblocks, or help needed do we have documented so far?”
This is the question that surfaces what’s visible and not yet visible. The team knows what they’re building. They don’t always have space to name what’s getting in the way or what they’re waiting on. Asking it explicitly, as the manager, creates that space without requiring you to know the technical answer.
✅ “What technical debt or accumulated shortcuts are we taking on here (or paying down)?”
Every significant piece of work either creates future complexity or addresses existing complexity. You don’t have to understand the specifics of that complexity (aka technical debt) to ask whether it’s being tracked. This question signals to the team you care about the long-term health of the work, not just the immediate output. That matters more than most managers realize.
When I left that manager’s office I told her the same thing I’ve told myself in every version of this situation: your job isn’t to be the smartest technical person in the room. It’s to create the conditions where the smartest technical people in the room can do their best work. That is a completely learnable, completely different skill set and it doesn’t require you to know everything first.
The fear that you’re not technically deep enough to lead effectively will probably not go away entirely. What changes, with time and practice, is your ability to recognize that the fear is telling you the wrong thing. It’s not evidence that you can’t do this. It’s evidence that you care and that’s a great starting point to take action from.
If this resonated, you might also like Issue #4, “When Your Team Knows More Than You Do”, which goes deeper on the 4 strategic shifts that changed how I lead technical experts. Paid subscribers have access in the subscriber section.
I’d appreciate your support at any level - free or paid - as it helps more leaders find Altitude! Thank you for being a reader and part of this community. You mean a lot to me.
I’d also love to hear your version of this. The moment you realized asking the question was sometimes more valuable than having the answer. Leave a comment, send a note, or find me on Substack Notes! I read everything and reply to as many as I can.
See you next Tuesday,
Kaleigh, I'm gonna have to steal question 3! I ask questions 1 and 2 when starting a new project (I'm an AI project manager), and the question about technical depth rings so many bells to me. My solutions architect loves to talk about impacts, that one project isn't just a standalone project, it affects other projects as well. And I think this is the technical debt that you are mentioning. Thanks for sharing this fresh perspective!
I really liked this perspective. It's reassuring to be reminded that leadership isn't about having all the answers. Sometimes asking the right question is far more valuable than having the right answer. Thanks for sharing this.