In the End, People Do the Work — What It Means to Respect People on a Software Team

Opening — The Real Cause of the Bug
The Nature of What Looks Like a Technical Problem
Concrete Behaviors of Respect
Conduct in Code Review and Debate
Diversity and Inclusion — Different Perspectives Make Better Outcomes
Anti-Pattern — The Trap of the Genius Myth
A Case — The Rude Genius vs the Kind Helper
Three Stories from the Field
A Blameful Retro vs a Blameless Retro
The SBI Feedback Framework
A Sample Dialogue — Hostile vs Respectful 1:1 Feedback
The Counterpoint — When Psychological Safety Is Misused
- Psychological Safety ≠ Exemption from Accountability
- The Risk of Toxic Positivity
Frequently Asked Questions
A Respect Checklist for the First 30 Days of Onboarding
A Practical Checklist
Closing
References

Opening — The Real Cause of the Bug

In incident retrospectives, the most common surface-level cause cited is "a bug in some piece of code." But when you dig deep into a retro, the real cause is, surprisingly often, not the code but something between people.

Let me tell you about a case I lived through. A payment system produced a double-charge bug. The code itself could be fixed in two lines. Yet the retro revealed that a month earlier, a developer had already spotted the risk and mentioned it in code review. The review comment read: "If a retry happens here, couldn't this lead to a double charge?" The reply to that comment was a single line: "No time right now, will look later." And nobody ever looked later.

The real cause of the bug was not the code, but the fact that the comment wasn't taken seriously. The person who raised it felt ignored, and afterward grew quieter and quieter in reviews. This was not a technical problem; it was a problem of people and communication.

Software is executed by computers but built by people. People gather to decide, debate, and sometimes argue as they build it. So "respect people" is not a warm slogan but a practical condition for building good software. In this essay I'll try to express that respect not as abstract preaching but as concrete behavior.

The Nature of What Looks Like a Technical Problem

Conflicts on a software team often wear the clothing of technical debate. "REST or GraphQL," "monolith or microservices," "is this variable name right or that one." But look underneath and you frequently find these non-technical problems lying at the base.

Surface (looks technical)	Substance (people / communication problem)
Endless architecture debate	A power struggle over whose opinion is respected more
Code review turns hostile	Failing to separate critique from character
The same mistake repeats	No safety to admit mistakes honestly
Information isn't shared	Absence of trust and cooperation
Meetings run long with no conclusion	Unclear decision authority

Of course, purely technical debates exist too, and reducing every conflict to a people problem is just as dangerous. The point is this: when a technical debate becomes abnormally heated or recurs, suspect whether a people problem lies beneath. Technical problems usually yield to data and experiments; people problems do not.

Concrete Behaviors of Respect

"Let's respect each other" is something everyone agrees with and that changes nothing. Respect must be a verb, not a noun. It has to show up in small daily actions.

Listening — Hearing People Out Without Interrupting

The most basic and the least observed. Don't cut in while someone is speaking in a meeting; even if you disagree, hear them out and ask back, "Let me check that I understood you correctly." This alone changes the atmosphere.

[A conversation without listening]
A: I think if we introduce a cache—
B: No, that won't work. Cache invalidation is so hard.
A: (falls silent)

[A conversation with listening]
A: I think introducing a cache could improve response time.
B: Good direction. My one worry is cache invalidation —
   how were you thinking of handling that?
A: Ah, by keeping a short TTL and—

The technical content of the two conversations is the same. The only difference is that one side treated the other as a person.

Credit — Attributing Contributions Accurately

If someone's idea solved the problem, name that person explicitly in the meeting, the document, the presentation. The single line "we solved it with the approach OO proposed last week" is a big form of recognition. Conversely, nothing destroys trust faster than quietly taking someone else's credit as your own.

Fairness — Treating People by Consistent Standards

If you're lenient with one person's mistake and harsh with another's, that is unfairness. If you wave through the PRs of people you like and nitpick the PRs of people you dislike, people will notice soon enough. Fairness comes from consistency of standards.

Respecting Time — Not Breaking Others' Focus Carelessly

Repeatedly breaking someone's deep work with "got a sec?" is also a lack of respect. Leave non-urgent questions asynchronously; keep meetings to only the people who need them, and keep them short. A colleague's time is a colleague's most precious resource.

Conduct in Code Review and Debate

Code review is where respect is most often tested. Code is the product of someone's time, and critiquing it is inherently sensitive.

Critique the Code, Not the Person

[A review that attacks the person]
"Why did you write it like this? Seems like your fundamentals are weak."
"I just can't understand this code at all."

[A review that focuses on the code]
"I think this part triggers an N+1 query. What about fetching in one go?"
"I'm having trouble following this flow — could you add a few more comments?"

The key principle is to "make the subject the code." Not "you are wrong," but "this code could cause a problem in this situation."

Borrow the Form of a Question

Questions are gentler than commands. "What about changing it like this?" gives the other person room to think, more than "change it like this." But avoid fake questions with a predetermined answer ("Do you really think this is the best you can do?") — those are even more aggressive.

Don't Try to Win the Debate; Try to Reach the Right Conclusion

The purpose of a technical debate is not to prove who's smarter but to make a better decision. The person who can say "I was wrong, your approach is better" is in fact the strongest. Disagreement is healthy, but once it's over you should follow the decision (disagree and commit) and leave no personal grudge.

Diversity and Inclusion — Different Perspectives Make Better Outcomes

Talking about diversity only as an ethical imperative easily rings hollow. There's a more practical view: a homogeneous team shares the same blind spots. When everyone has the same background, the same experience, the same way of thinking, everyone misses the same things.

People of different backgrounds ask different questions. One thinks of accessibility, another of users in a different language, another of a security threat. These varied questions add up to more robust software.

Inclusion goes one step beyond diversity. Beyond gathering varied people, it means actually enabling them to speak. If the same two or three people always talk in meetings, you have diversity but no inclusion.

Small practices that build inclusion
- In meetings, ask the quiet person directly for their view:
  "OO, how do you see this part?"
- Run async channels (docs, chat) alongside
  so people who find it hard to break in verbally can contribute
- Hear junior or minority opinions first, senior opinions later
  (if an authoritative opinion lands first, others get buried)

Anti-Pattern — The Trap of the Genius Myth

The software industry stubbornly clings to the "lone genius" myth — the fantasy that one extraordinary developer creates everything. This myth is harmful in two ways.

First, it isn't true. Almost every great piece of software we know was built by a team. Even Linux was built by thousands of contributors together, and Linus Torvalds himself stresses this more than anyone.

Second, it does damage. The person hailed as a "genius" is often excused for rudeness. "He's prickly, but he's brilliant" erodes the psychological safety of the whole team. The value a single brilliant individual creates can be smaller than the value lost when that person makes ten people around them shrink.

Google's Project Aristotle, an analysis of its own teams, points in the same direction. The single most important factor in building the best teams was not the genius of individual members but the team's psychological safety — an atmosphere where anyone can ask a "dumb" question and admit a mistake.

A few more anti-patterns worth naming:

Rewarding heroics: a culture that praises only the person who fights fires (rescues an incident at the last minute) over those who work calmly all along. In the end everyone learns to start fires.
Outsourcing silence: the attitude of "that's the other team's job," shifting responsibility. Problems fester at the boundaries.
Contagious cynicism: the person who answers every proposal with "we tried that before, it doesn't work." One cynic kills ten attempts.

A Case — The Rude Genius vs the Kind Helper

Let me compare two senior developers. Both were highly skilled.

S was the classic "rude genius." The code was excellent, but the reviews were harsh, and S frequently cut others off in meetings. Juniors were afraid to ask S questions and couldn't say they didn't know something. As a result, the same mistakes quietly recurred.

D was different. The code wasn't quite as good as S's, but D answered juniors' clumsy questions seriously and disclosed his own mistakes first. "I made this exact error last year," he'd say. Over time, the juniors around D grew fast, and the whole team's productivity rose.

A year later, comparing the teams' output, the team D belonged to produced more, and more reliably. A single line of S's code may have been better, but the team D built was stronger. This is the meaning of "in the end, people do the work."

Three Stories from the Field

Abstract principles only come alive inside concrete stories. Through three cases I either watched closely or heard firsthand, let me trace how respect — or its absence — decided a team's fate.

Case 1 — The Senior Who Left After Credit Was Stolen

A remote team had a senior engineer named J. J spent days cracking a thorny data-consistency problem in a distributed system and wrote it all up in a long, careful post in the team channel. The trouble came next. The team lead presented that solution to executives as if he had designed it himself, and J's name never came up once.

Because it was remote, J wasn't in that meeting. When J later learned about it through the meeting notes, he said nothing at first. But when the same thing happened two or three more times, J quietly began to contribute less. He stopped sharing his solutions to hard problems publicly, and half a year later he left the company. What he said in his exit interview was short: "I can't find a reason to work somewhere my work doesn't stay mine."

The lead never understood the real reason J left. On the surface it was "a better offer elsewhere." But what the team lost was not one person; it was the entire capacity to solve the hardest problems that person used to solve. Attributing credit accurately is not a matter of manners but a matter of talent retention.

Case 2 — A Heated PR Thread, and How It De-escalated

Another case unfolded during an open-source contribution. A contributor opened a large refactoring PR, and a maintainer tried to close it with a terse comment: "This change doesn't fit our design philosophy." The contributor bristled, and the thread turned hostile fast. "Then you should have written it in the guidelines from the start." "You clearly haven't read the codebase properly." Both sides had started aiming at the person.

What saved this thread was a third party. Another maintainer stepped in and wrote: "It seems you both want the same thing — a cleaner codebase. You just have different assumptions about how to get there. First, the fact that we never documented our agreed design principles anywhere is on us. What if we start by writing those down, and then revisit this PR split into smaller pieces?"

That single comment changed the whole atmosphere. It (1) named the shared goal of both sides, (2) took part of the responsibility onto the maintainers, and (3) proposed a concrete next action. In the end the contributor split the PR into three, two of which were merged, and later became an official maintainer. Turning a conflict from a clash of egos back into problem-solving often takes nothing more than one person reminding everyone that "we're on the same side."

Case 3 — A Blameful Retro vs a Blameless Retro

Let me compare how two teams retrospected on the same incident. Both suffered a 30-minute outage caused by a database migration mistake after a deploy.

Team A's retro started with "who did this." The junior who ran the migration was singled out, and throughout the meeting that person couldn't lift their head. The conclusion was "let's be more careful next time." From then on, the junior became terrified of deploying, and others began passing risky work to one another. A month later, a similar mistake happened again, at someone else's hands.

Team B's retro started with "how was this possible." Instead of blaming the person who ran the migration, the questions aimed at the system. "Why could a dangerous migration reach production without automated validation?" "Why did the rollback take a full 30 minutes?" The conclusion was not a person but guardrails — automated pre-validation of migrations, one-click rollback, staged rollout. The junior was actually put in charge of building the validation tool. A similar mistake never happened again.

Same incident, opposite outcomes. The only difference was whether the retro aimed at the person or the system.

A Blameful Retro vs a Blameless Retro

The difference between the two retro styles can be summarized in a table.

Aspect	Blameful Retro	Blameless Retro
First question	Who did this	How was this possible
Focus	The individual's mistake	The system's gaps
Atmosphere	Defense and excuses	Curiosity and learning
Output	A vow to be more careful	Concrete guardrails and action items
Disclosure	People hide mistakes	People surface mistakes early
Long-term effect	The same mistake repeats	The same mistake is blocked
Psychological safety	Declines	Rises

The core assumption of a blameless postmortem is simple. You assume people acted reasonably given the situation, and then you ask why that action looked reasonable to them. This assumption moves people from defense mode to learning mode. Etsy's "Blameless PostMortems and a Just Culture" is a classic starting point for this approach.

The SBI Feedback Framework

Respectful yet honest feedback doesn't come out on the fly. It needs structure. One of the most practical tools is the SBI framework: state Situation, Behavior, and Impact, in that order.

Situation: Pin down when and where it happened, concretely. As in "in yesterday afternoon's sprint meeting."
Behavior: State only observable facts. Not interpretation or guesswork, but only behavior a camera could have captured. As in "you interrupted twice before the colleague finished speaking."
Impact: State the effect that behavior had on you or the team. As in "so they couldn't finish their point, and I think a good idea got buried."

The power of SBI lies in turning a character judgment like "you're rude" into an observation: "in this situation, this behavior had this effect." The listener has less to defend against.

[SBI in practice]
Situation (S): In yesterday afternoon's design review,
Behavior (B): you cut me off twice with "that won't work"
              before I'd finished explaining the cache plan.
Impact (I):   So I never got to explain the invalidation
              strategy, and I felt my point didn't land.
Request:      In the next review, if you give your counter
              after I've finished, I think we can go deeper.

The closing "request" isn't formally part of SBI, but it helps end feedback as a proposal to collaborate rather than as a critique.

A Sample Dialogue — Hostile vs Respectful 1:1 Feedback

Let me compare two 1:1 conversations over the same situation and the same problem. A team member has recently missed two deadlines.

[A hostile 1:1]
Lead: What's going on with you lately? You've already
      missed two deadlines. At this rate you're a burden
      on the team.
Member: I'm sorry... I've just been busy.
Lead: Everyone's busy. No excuses, just do it properly.
Member: ...okay.
(The member never reveals the real reason.
 The next deadline is shaky too.)

[A respectful 1:1]
Lead: Two deadlines slipped recently, and I'd like to
      look at what happened together. Not to blame you —
      if something's blocking you, I want to clear it.
Member: Honestly... I kept getting stuck on the payment
        module dependency. Their API changes often, so
        I had to rewrite my code.
Lead: Ah, that's not something to carry alone. I'll join
      the coordination with that team. And from now on,
      if you raise blockers like this early, we can clear
      them much faster.
Member: Okay, I'll do that. I was hesitant to bring it up.
Lead: Telling us what's blocking you is doing the job well.
(The real cause surfaces and leads to a structural fix.)

The facts of the two conversations are identical: the member missed two deadlines. But the hostile conversation made the real cause stay hidden, while the respectful one brought it out and led to a fix. The difference between honesty and rudeness isn't whether you face the problem head-on; it's whether you treat the other person as an enemy or as an ally.

The Counterpoint — When Psychological Safety Is Misused

For this essay not to lean too far one way, we owe it a counterpoint for balance. Respect and psychological safety are powerful tools, but used wrongly they produce the opposite of what's intended.

Psychological Safety ≠ Exemption from Accountability

The most common misreading is "psychological safety = a state where no one is ever challenged." That is wrong. As Amy Edmondson herself stresses, psychological safety must pair with high standards. With high safety but low standards, a team sinks into a "comfort zone"; with high standards but low safety, it falls into an "anxiety zone." Only when both are high do you get the "learning zone" of high performance.

"It's okay to make mistakes" is not "it's okay not to be accountable for mistakes." A blameless retro is not "a retro where no one is accountable," but "a retro where the system and the process take responsibility instead of blaming an individual." If the same person repeats the same mistake without learning and it's let slide every time without a word, that isn't psychological safety; it's neglect.

The Risk of Toxic Positivity

Another trap is a culture of "let's only speak positively" that ends up suppressing honest problem-raising. If every meeting is filled only with "great" and "awesome," and someone who points out a risk gets met with "why are you so negative," that team looks harmonious on the surface but actually loses important signals. Recall the payment bug from the opening. The warning comment was buried not only because of rudeness but also because of an atmosphere that didn't take uncomfortable truths seriously.

Real respect isn't "saying only what's pleasant to hear"; it's "saying what's necessary, even when uncomfortable, in a way that respects the other person." In Kim Scott's terms, it's both caring personally and challenging directly. With only one of the two, you get either a rude attack or ruinous empathy.

Frequently Asked Questions

Q. What's the difference between honesty and rudeness?

The target differs. Honesty aims at the problem; rudeness aims at the person. "This design will probably break under this load" is honesty. "I doubt your skills, designing it like this" is rudeness. Another test is intent. People instinctively distinguish honesty that wishes the other well from rudeness that tears them down to elevate oneself.

Q. Isn't disagree-and-commit just forcing silence?

The order is the key. Disagree-and-commit means "commit after you've disagreed enough," not "just shut up and follow." If you were given ample chance to dissent, your view was seriously considered, and only then a decision was made, you don't keep shaking that decision at the execution stage. If you're asked to commit without even a chance to disagree, that's a misuse of the principle.

Q. How do you show respect in a remote environment?

Remotely, nonverbal cues disappear, so respect has to be expressed more explicitly. A few concrete practices: leave credit clearly in text (write "this was OO's idea" in the channel); add at least a quick reaction emoji to async messages to signal "I read this and didn't ignore it"; deliberately call on quiet people in video meetings; don't force a colleague in another time zone to answer at dawn. J in Case 1 left precisely because, being remote, the credit theft happened more invisibly.

Q. How should you handle someone who is rude but highly skilled?

First, widen the definition of "skilled." Someone who makes the people around them shrink and lowers the team's overall output can have a negative net contribution, no matter how strong their individual work. The way to handle it is to convey clear expectations in the language of behavior (see SBI above). Not "you're rude," but "when you use personal attacks in reviews, people stop asking questions, and that blocks the team's learning." Give room to change, but if they don't, you have to honestly compute the loss their skill leaves on the team.

Q. I'm new and afraid to voice opinions. How do I start?

Borrowing the form of a question is the safest starting point. Instead of "this is wrong," ask "I might be misunderstanding this part, but if we do it this way, what happens in this case?" — if you're wrong you're learning, and if you're right you've flagged a problem. Also use async channels. If breaking in verbally in a meeting is hard, leaving your view in a doc comment or chat carries less pressure.

Q. My team already has built-up distrust. Where do we start?

Repeated small actions restore trust more than one big declaration. If you're a leader, start by disclosing your own mistakes first. The single line "I misjudged this decision" signals to everyone else that "it's safe to admit mistakes here." And keep small promises, repeatedly. Trust is built not by grand events but by the accumulation of small promises kept.

A Respect Checklist for the First 30 Days of Onboarding

How you welcome a new joiner reveals a team's culture of respect more sharply than anything. Here's a checklist for the first 30 days.

[Day 1]
- [ ] Post a public welcome message in the team channel
- [ ] Verify in advance that the dev-environment setup doc is current
- [ ] Explicitly say "you can ask anything, anytime"
- [ ] Greet person-to-person first, over lunch or a light 1:1

[Week 1]
- [ ] Assign one mentor or buddy
- [ ] Pick a small, safe first task together (one easy PR)
- [ ] Leave an especially warm, concrete review on that first PR
- [ ] Prove with real reactions that "there are no dumb questions"

[Week 2]
- [ ] Explain how the team makes decisions and how authority is structured
- [ ] Share major past decisions and their context (why things ended up this way)
- [ ] Ask the new person directly for their view at least once in a meeting

[Day 30]
- [ ] In a 1:1, exchange honest feedback both ways on "how it's gone so far"
- [ ] Take seriously the "why do you do it this way?" questions from their fresh eyes
      (an outside view lights up blind spots we can't see)
- [ ] Publicly recognize even small contributions and name them

The naive "why do you do it this way?" a new joiner asks in their first month is in fact the most valuable asset. It re-illuminates the things we've grown too used to to question anymore. The moment you shut that question down with "that's just how it is," the team loses one outside pair of eyes.

A Practical Checklist

Closing

The quality of software ultimately reflects the quality of the relationships among the people who built it. Code built by a team that doesn't respect one another carries that distrust subtly engraved in it — in unshared information, unaddressed warnings, and the silence of people who closed their mouths.

Respecting people isn't a grand undertaking. Hearing people out, attributing credit accurately, critiquing the code without critiquing the person, and making it safe to say "I don't know." These small actions stack into a good team, and a good team builds good software.

Please remember: what we build is code, but who we work with is people. And in the end, software is the work of people.

References

Google re:Work, "Project Aristotle" — https://rework.withgoogle.com/
Amy Edmondson, The Fearless Organization (psychological safety) — https://hbr.org/2023/02/what-is-psychological-safety
Brian Fitzpatrick & Ben Collins-Sussman, Team Geek / Debugging Teams (critique of the genius myth) — https://www.oreilly.com/library/view/debugging-teams/9781491932049/
Google Engineering Practices, "Code Review Developer Guide" — https://google.github.io/eng-practices/review/
Kim Scott, Radical Candor — https://www.radicalcandor.com/
Harvard Business Review, "The Power of Saying I Was Wrong" — https://hbr.org/
Etsy Code as Craft, "Blameless PostMortems and a Just Culture" — https://www.etsy.com/codeascraft/blameless-postmortems/
Atlassian Team Playbook — https://www.atlassian.com/team-playbook
Will Larson, "Irrational Exuberance" (engineering leadership) — https://lethain.com/