Software Engineer One-on-One Meeting Questions: What to Ask Your Manager and Why It Matters

Engineering work creates a weird management problem. A lot of your real value is invisible unless someone asks good questions and pays attention over time. The clean migration, the production incident you prevented, the technical debt you quietly removed, the mentoring you gave a junior teammate, the warning sign you noticed before a launch, none of that always shows up in a simple task count.

That is why one-on-ones matter. They give context to your work. They let your manager understand not only what you shipped, but where you are stuck, where your leverage is growing, and where your energy is dropping.

Asana recommends weekly or biweekly one-on-ones of roughly 30 to 60 minutes, with newer hires and newer manager relationships usually benefiting from more frequent meetings. That feels right to me. Engineers early in role changes need tighter feedback loops because ambiguity is high and assumptions are fragile. Lattice’s 2026 guidance also argues that different types of questions serve different purposes, from wellbeing and check-ins to tactical alignment and career development. In other words, a good 1:1 is not one generic conversation repeated forever. It shifts depending on what you need.

There is also a retention angle here. Lattice points to career progression research showing that employees are much more likely to leave when they feel dissatisfied with growth opportunities. That should not surprise anyone in tech. Developers rarely quit only because of code. They quit because they feel stalled, unseen, unsupported, or mismanaged. One-on-ones are where those problems first become fixable.

For software engineers specifically, the best one-on-ones do four things. They make priorities clearer. They surface blockers sooner. They improve trust between you and your manager. And they create a record of growth over time. If your 1:1 is not doing at least some of that, it is underperforming.

Use your one-on-one for things that are hard to do anywhere else. That sounds obvious, but it is the easiest filter for deciding what belongs.

Bad use of a 1:1 looks like this: a rapid-fire list of ticket updates, a random complaint session with no goal, or a vague “everything is good” conversation that produces nothing. Good use looks like this: clarifying tradeoffs, asking for candid feedback, discussing long-term growth, getting help with cross-team friction, understanding how your work is perceived, and aligning on what matters most.

I like to think of the meeting in five buckets.

• Clarity: What matters most right now, and what does good look like?
• Support: What is blocking me, and how can you help?
• Feedback: What should I keep doing, stop doing, or improve?
• Growth: What skills, scope, or behaviors would raise my level?
• Visibility: Is the right work being seen and valued?

If your agenda touches one or more of those buckets each time, the meeting will usually be worth having.

One more thing matters a lot. Bring your questions in writing. Lattice, Assembly, and other current guidance all push some version of a shared or recurring agenda. That is not bureaucracy. It is memory. Without written prompts, your 1:1 gets hijacked by whatever happened in the last 90 minutes. With a running list, you can spot patterns, follow up on commitments, and stop having the same frustrating conversation every month.

My recommendation is simple. Keep a private or shared note with three sections: current blockers, growth topics, and questions. Add to it throughout the week. Then arrive at the meeting with your best two or three questions, not fifteen random thoughts.

These are the questions that keep you from working hard on the wrong thing. They are especially useful when priorities feel muddy, projects keep shifting, or leadership language is broad and fuzzy.

• What are the top one or two outcomes you most want from me this sprint or month?
• If everything on my plate cannot get done, what should win?
• What does strong performance look like on this project from your perspective?
• Where do you think I might be overinvesting or underinvesting effort?
• Is there work I am doing that feels lower leverage than it looks to me?
• What context from leadership or other teams would help me make better tradeoffs?

These questions work because they force specificity. Managers often think they are being clear when they are actually being broad. “Drive impact,” “show ownership,” and “move faster” sound useful until you ask what they mean in your actual situation. The right question turns abstract expectations into something you can act on.

If you are a junior engineer, these questions help you find the edges of your role. If you are senior, they help you calibrate your energy toward the work that actually moves the business. Either way, they reduce silent misalignment, which is one of the most common reasons good engineers get mediocre performance feedback.

A lot of developers wait too long to escalate friction because they want to look capable. I get it. Nobody wants to sound helpless. But strong engineers do not pretend blockers do not exist. They surface them early and clearly.

Use questions like these when you need help without turning the meeting into a helpless shrug.

• I keep hitting this blocker. What is the best path to unblock it from your perspective?
• Am I treating this as my problem to solve when it actually needs escalation?
• Who should I pull in earlier on this kind of issue next time?
• What is the fastest acceptable version of this solution if time gets tight?
• Where do you want me to push harder versus ask for support sooner?
• Is there organizational context I am missing that explains why this keeps getting stuck?

The point is not just to get rescued. It is to get better at understanding the system around you. In software teams, blockers are often social or organizational before they are technical. The API contract is unclear because product changed direction. The migration is slow because nobody owns the risk decision. The code review drags because another team has different incentives. A good manager can often expose the real shape of the problem faster than you can from your seat.

If you are remote, this category matters even more. Friction stays hidden longer in distributed teams. The one-on-one is one of the few places where you can say, plainly, “this is stuck and I need a better way through it.”

This is where a lot of engineers undershoot. They ask, “Any feedback for me?” and their manager says, “No, you’re doing great,” because that question is too wide, too lazy, and too easy to dodge.

If you want useful feedback, ask narrower questions.

• What is one thing I am doing well that you want me to keep leaning into?
• What is one habit or behavior that would make me more effective if I improved it?
• How is my communication landing with the team?
• Where do you think I am stronger than my title suggests?
• Where do you think I am not yet operating at the next level?
• When you advocate for me, what strengths do you mention, and what concerns might you mention?

Those questions are much harder to answer with fluff. They invite observation instead of generic reassurance.

Engineering-focused advice from places like Waydev and EM Tools also reinforces a useful principle here: one-on-ones should not just be status updates. They should surface how work is going, what support is needed, and what patterns are showing up. Feedback is part of that pattern detection. The goal is not to fish for compliments. It is to get signal early enough to adjust.

If your manager still gives shallow answers, follow up with examples. Ask, “Can you point to a recent situation where that showed up?” Examples are where real feedback starts.

If you do not ask about growth until review season, you are making your life harder than it needs to be. Promotions almost never come from one heroic quarter. They come from repeated evidence over time, and one-on-ones are where you learn what evidence actually counts.

Good growth questions include:

• What skills or behaviors would most help me level up from here?
• What kind of work would give me better exposure to the next level?
• If I wanted to be promotion-ready in the next cycle, what would you need to see?
• Where do you think my growth edge is right now, technical depth, communication, ownership, or influence?
• What projects would stretch me in a healthy way?
• Who on the team is especially strong in an area I should learn from?

This is where one-on-ones become career insurance. Lattice’s 2026 guidance emphasizes development and career growth questions as a distinct category, not an occasional afterthought. That matches reality. Strong developers do not just hope their manager notices growth. They make development legible.

One question I especially like is: What would make you confident putting me in charge of something bigger? It gets straight to trust, not just output. Promotions often hinge on whether your manager believes you can operate with more ambiguity, more coordination, and more judgment. That question helps you see what is missing.

And if the answer is vague, press kindly. “Can you give me one concrete example?” is a very fair follow-up.

Sometimes the problem is not your coding. It is the environment around the coding. That is worth bringing into your 1:1 too.

• Where do you think our team process is helping versus slowing us down?
• Are there communication patterns on the team you want me to adapt to more effectively?
• What is one recurring source of friction you think we should fix?
• How do you think cross-team collaboration is going from your perspective?
• What would you want me to do if I see a process problem repeating?
• How can I raise concerns about quality, deadlines, or tradeoffs in a way that is most effective here?

Lattice’s recent one-on-one guidance includes team dynamics and collaboration as its own question category for a reason. Software work is collaborative by default. If your design process is chaotic, your team has review bottlenecks, or product-engineering trust is eroding, that will shape your performance more than individual hustle can overcome.

These questions are especially important for senior engineers and tech leads, but honestly, juniors benefit from them too. Early in your career, understanding team dynamics helps you avoid misreading normal friction as a personal failure. It also helps you learn how influence actually works in your organization.

Remote engineers need a slightly different set of questions because visibility, communication, and support all behave differently when you are not in the same room. Good remote 1:1s should compensate for missing hallway context.

• Do you feel like my work and impact are visible enough, or should I communicate progress differently?
• Where do async updates work well for us, and where would live discussion help more?
• Are there meetings or decisions I am too far from right now?
• Do you see any signals that I am under-communicating or over-communicating remotely?
• What is one way I could collaborate more effectively across time zones or functions?
• Are there opportunities I might be missing because I am not hearing the informal context?

Remote engineering can create a false sense that everything is documented when a lot of important interpretation still happens in people’s heads. These questions help you pull hidden context into the open. They also help prevent a common remote-career problem: being productive but strategically invisible.

If you are remote and feeling disconnected, say it plainly. Do not wait until you are quietly resentful. A good manager should want to know that your access to context or opportunity feels weaker than it should.

The biggest mistake is treating the meeting like it belongs to your manager. It does not. It belongs to both of you, and you should use your half of it.

The second mistake is arriving empty. If you show up with nothing prepared, the meeting gets filled by whatever is easiest to discuss, and that is usually shallow status chatter.

The third mistake is only bringing problems, never goals. One-on-ones should absolutely surface blockers and frustrations, but if every meeting feels like a complaint bucket, you are missing the growth side of the conversation.

The fourth mistake is asking broad questions that invite bland answers. “How am I doing?” is weak. “What is one thing that would make me more effective at senior-level work?” is much better.

The fifth mistake is never following up. If your manager said they would help with something, ask about it next time. If you committed to improving something, report back. Strong one-on-ones create continuity. Weak ones reset every week like nobody has memory.

And finally, do not confuse vulnerability with vagueness. It is fine to say you are struggling, uncertain, or frustrated. Just be concrete. Specificity is what makes support possible.

If you want an easy structure, use this five-part template.

1. Quick check-in: energy, mood, any urgent context.
2. Blockers and decisions: what is stuck or unclear.
3. Feedback: one question about how you are operating.
4. Growth: one question about skills, scope, or career direction.
5. Next steps: who is doing what before the next meeting.

Here is what that can sound like in practice.

Check-in: “This week feels fine overall, but I am stretched between delivery and design work.”

Blocker: “I need help deciding whether to keep pushing on the migration or cut scope.”

Feedback: “How did my communication land during the incident review?”

Growth: “What would help you trust me with more cross-team ownership?”

Next steps: “I will draft the proposal. You will connect me with the platform lead. We will revisit this next week.”

That is a real one-on-one. It is focused, honest, and useful. No corporate theater required.

The goal is not to impress your manager with thoughtful conversation. The goal is to create better outcomes, clearer thinking, and stronger career momentum.

Great software engineers do not just solve technical problems. They learn how to reduce ambiguity around their work, ask for better signal, and build trust with the people who shape their environment. One-on-ones are one of the few recurring places where all of that can happen on purpose.

If you remember only one thing from this page, remember this: the quality of your 1:1 is often the quality of the questions you bring into it. Good questions create better feedback, better support, better visibility, and better decisions. Weak questions create polite nothing.

So do not walk into your next one-on-one hoping the meeting becomes useful by accident. Bring one question about priorities, one about feedback, and one about growth. Write them down. Ask them directly. Listen carefully. Then follow through.

That alone will put you ahead of a lot of engineers, because most people are still treating one of their most valuable meetings like calendar filler.

What should software engineers talk about in a one-on-one? Focus on priorities, blockers, feedback, growth, and team dynamics. A good 1:1 should go beyond status updates and help you get clarity, support, and career signal.

How often should a software engineer have a 1:1 with their manager? Weekly or biweekly is usually best. Asana’s current guidance says 30 to 60 minutes weekly or biweekly works for most teams, with newer hires and newer manager relationships often benefiting from weekly meetings.

What are the best one-on-one questions to ask your manager? Strong questions are specific. Ask what matters most right now, what strong performance looks like, what behaviors would help you level up, and where your manager sees risk or opportunity in how you are operating.

Should a one-on-one be used for status updates? Only lightly. Quick context is fine, but if the whole meeting is a ticket rundown, you are using expensive time for something that could have been async.

How do I ask for feedback without getting a vague answer? Ask narrow questions. Instead of “Any feedback?” ask “What is one thing I should improve to operate at the next level?” or “How did my communication land in that project?” Narrow questions pull better answers out of busy managers.

What if my manager is bad at one-on-ones? You can still improve the meeting by bringing a written agenda, asking specific questions, and following up on commitments. If the meeting stays consistently shallow, that itself becomes a signal about management quality and support.