At the staff level, a significant number of your 1:1s are ones you initiate — with peers you need to work with, with stakeholders whose teams are upstream or downstream of yours, with leadership whose support you need for technical direction you’re trying to establish. These are different from the 1:1s you were trained on. The dynamics are different, the stakes are different, and the mistakes are different.

This post is about how to run the first one well.

Who Are You Meeting With?

The “first 1:1 as a staff engineer” context applies to a handful of distinct relationships, and the right approach differs slightly for each:

A new peer staff engineer. You’re meeting a counterpart from another team or org. You have symmetrical standing. The goal is to establish a working relationship — to understand what they’re doing, where your work intersects, and how you might be useful to each other.

A new stakeholder (non-engineer). A product manager, designer, data scientist, or business partner whose team your work affects. The goal is to understand their perspective, establish credibility, and find the shared interests that make future collaboration smoother.

A new skip-level or senior leadership. A VP, director, or senior individual contributor who is above you in some chain of authority or influence. The goal is to establish that you exist, that you’re thoughtful about your work, and to learn what they care about in a way you can’t get from your direct manager.

A peer in a new reporting structure after a reorg. A relationship you technically had before, but that is effectively new because the context and dependencies have changed.

The preparation and conduct is similar across all of these, but the specific questions and framing differ.

What a First 1:1 Is Not

Before getting into what to do, it helps to be clear about what the meeting is not for:

Not a status update. If you fill a first 1:1 with a rundown of what your team is working on, you’ve established yourself as a person who gives updates, not someone they need to think with. Updates have their place — in written form, ahead of the meeting, or in separate channels.

Not a pitch. Bringing an agenda and trying to get alignment on something you want in a first 1:1 with someone you don’t know signals poor social calibration. First meetings are for learning, not persuading.

Not an interview. Asking rapid-fire questions about their work, team, and priorities feels extractive and transactional. Questions should feel curious, not thorough.

Not a performance. The instinct to demonstrate your competence, drop impressive context about your projects, or signal that you operate at a certain level often backfires. Competence shows through the quality of your questions and engagement, not through statements about your work.

Before the Meeting

Spend 15 minutes on research: LinkedIn, recent internal documents, their team’s public outputs (blog posts, RFCs, design docs). You want enough context to ask informed questions, and to avoid wasting their time on things you could have learned without them.

Three things to know going in:

1. What does their team own? Specifically — what systems, what features, what domain.
2. Where does your work touch theirs? Shared dependencies, upstream/downstream relationships, overlapping roadmap items.
3. What do they care about that you can genuinely help with? Not what you want from them — what they want that you might provide.

The research isn’t to script the conversation. It’s to show up knowing enough that your questions land as informed and specific, not as generic ice-breakers.

How to Open

The standard opening is worth following: brief, honest context about why you’re meeting.

For a peer: “I wanted to connect directly because our teams are going to be working more closely on [X], and I’d rather understand your perspective before we’re in the middle of something.”

For a stakeholder: “I wanted to get a better understanding of what your team is trying to accomplish, so I can make sure what we’re building is actually useful for you rather than just technically correct.”

For a skip-level: “I’ve been wanting to get time with you directly. I’d like to understand what you’re thinking about at the org level and share a bit about what I’m working on — not for alignment, just to build context.”

Each of these is honest about the purpose without being either servile or transactional. They set a tone of candid exchange.

Questions That Work

The goal is to learn things you couldn’t learn from documentation, and to demonstrate that you’re worth thinking with. The questions that accomplish this share a few properties: they’re specific enough to show you did your homework, open-ended enough to invite genuine reflection, and focused on their perspective rather than your information needs.

A few examples:

For a peer:

• “What’s the part of your team’s work that’s most underestimated by people outside your team?”
• “Where do you think we’re most likely to step on each other’s toes before either of us realizes it?”
• “What would make our collaboration more valuable from your end — what’s the thing we could do differently that would have the most impact for you?”

For a stakeholder:

• “What’s the biggest gap between what engineering delivers and what you actually need — the thing that’s hardest to articulate in a requirements doc?”
• “If you had to identify the one place where a technical decision in the last year created the most friction for your team, what would it be?”

For a skip-level:

• “What’s the problem you’re most focused on solving at the org level right now that doesn’t have a clear owner?”
• “Where do you think this org has the most technical leverage it’s not currently using?”

These questions are not magic formulas — adapt them to the actual context. The common thread is that they invite the other person to share genuine perspective rather than information they’d give to anyone.

Listening and Following Up

The most common mistake in first 1:1s is listening to respond rather than listening to understand. When they answer a question, your instinct will be to map their answer to what you already know — to confirm your model, add a data point, or transition to your next question. Resist it.

Before responding, let the answer be complete. Then ask one more question about what they just said before you move on. “When you said [X] — what does that look like in practice? Can you give me a specific example?” This deepens the conversation and signals that you’re actually engaging rather than running through a list.

After the meeting, a brief follow-up note is worth doing: one or two sentences about what you found most valuable, and any specific action you’ll take based on what you heard. “Thanks for the time. The point about [X] was something I hadn’t thought about that way — I’m going to talk to [person] about it. Let me know if there’s anything from my side that would be useful to you.”

Short, specific, and action-oriented. Not a summary or a recap — a signal that the conversation mattered and that you’re acting on it.

What to Notice and Remember

A first 1:1 is valuable primarily as a way to calibrate your mental model. What you’re trying to walk away with:

• Their actual priorities — not the stated priorities from the roadmap, but what they personally care about getting right
• Where they feel friction — with their team, with other teams, with the current technical direction
• How they think — whether they’re intuition-driven or data-driven, whether they see problems as political or technical, whether they’re optimistic or skeptical by default
• What they want from you — not what they said, but what you infer from what they asked and how they responded to different topics

Log these observations somewhere. Not as a dossier — as a reference. Over the next few months, your model of this person will update as you work together. The first-meeting notes are a useful baseline.

The relationship you’re building is a long one. The first 1:1 is its beginning — worth getting right, not worth overthinking.

VividMap helps you track the relationships that matter to your career, log context from key conversations, and maintain a map of who to know in a changing org. See how it works.