Working with people
Collaboration and disagreement
Build trust before you need it, disagree with data and options, and make cross-team asks easy to grant.
Software is a team sport with incomplete information. You will disagree about designs, timelines and ownership. You will need help from people who do not report to you. The engineers who stall at mid-level are often technically strong but unable to move work through other humans. Collaboration is not "being nice." It is getting to a good outcome with people who have different incentives, information and stress levels.
Why this matters
SDE2 scope usually means leading collaboration inside a team and starting to pull other teams without a staff engineer doing it for you. Interviewers listen for stories where you influenced without authority, de-escalated conflict and made a hard trade-off stick. Collect those stories as they happen — a paragraph after a sticky week is enough.
If your team has no norms yet, propose two lightweight ones: decisions written down with owner and date, and disagreements resolved with options-plus-recommendation rather than endless threads. Norms beat heroics.
Concepts in this section
Read them in order.
| Step | Concept | What it answers |
|---|---|---|
| 1 | Building trust | What credit do you earn before you need a rushed yes? |
| 2 | Disagreeing well | How do you argue, decide and then execute? |
| 3 | Influence without authority | How do you get an API change from a team you do not manage? |
| 4 | Cross-team asks | How do you make saying yes the easy path? |
| 5 | Glue work | How do you do connective work without disappearing from the packet? |
| 6 | Psychological safety | How do people challenge a plan without being punished? |
A worked pattern
You need payments to add an idempotency key. They are mid-roadmap. Homework, optional header shipped dark, a sketch PR in their style, shared upside ("protects you from duplicate charges"), a dated week if they cannot do it now. If they refuse a "quick" schema change three times, document the 2× maintenance cost of your compatibility layer and ask once: schema change this quarter, or an extra engineer-week per quarter forever?
That is influence: you changed their incentive, not their mood.
Common mistakes
- Trust only when you need it. Every ask then feels extractive. Deposit in quiet weeks.
- Naked disagreement. "I disagree" with no facts, options or recommendation.
- Relitigate after the decision. Execute, or reopen with new evidence.
- Invisible glue. You saved the launch; the packet lists PRs. Write the alignment.
- Public shame. Handle teammate conflict privately and early.
Key takeaways
- Deposit trust: keep commitments, share context early, make others' work visible.
- Disagree with facts, options and a recommendation; steelman first; disagree-and-commit after.
- Cross-team asks succeed when you understand incentives and make yes easy.
- Glue work is real — make it visible, time-box it and check how your ladder values it.
- Safety plus accountability lets people challenge plans without fear.
Further learning
Being Glue (Tanya Reilly)Slides and notes for the Being Glue talk.No Idea Blog The Staff Engineer's Path (Tanya Reilly)oreilly.comTanya Reilly's LeadDev talk on glue work:
Amy Edmondson on psychological safety:
Related
Written and verbal communication
Lead with the point, write for skimmers, and adjust depth for engineers, PMs and executives.
Code review
Author small, reviewable PRs and give reviews that improve both the code and the author — design first, tone that teaches, turnaround that unblocks.
Working with product managers and designers
Product sense for engineers — shaping scope, trade-off conversations, feasibility spikes, and building the right thing with PMs and designers.