Kind Engineering: Why Being Kind Makes You a Better Engineer

There is a phrase that gets said in teams quietly, often between engineers who've been around long enough to have felt its absence: "I can say what I actually think here." It sounds simple. In practice, it's rare — and enormously valuable. The conditions that make it possible don't arrive by accident. They are built, one interaction at a time, by people who choose to be kind.

Not nice. Kind. The difference matters more than it first appears, and getting it wrong costs teams dearly.

This article is a practical exploration of what kind engineering actually means — in the everyday moments of code reviews, incident calls, feedback conversations, and the quiet choices about how we treat the people we work with. Much of the thinking here was shaped by kind.engineering, a resource I'd recommend to anyone who cares about building healthy teams. The ideas below are my own synthesis and experience; consider that site essential further reading.

Kind is not the same as nice

The confusion between kindness and niceness is responsible for a surprising number of dysfunctional teams. Niceness is comfortable — it smooths over awkward moments, keeps the peace, and feels warm. But it's often hollow. A nice person tells you the demo looked great when it had a critical flaw. A nice person approves the pull request rather than leaving a comment that might seem critical. A nice person agrees in the meeting and stays quiet while a bad decision moves forward.

Kindness is different. Kindness tells you the truth because it cares about you. It says the hard thing, but says it in a way that makes you want to grow rather than hide. The author at kind.engineering captures this beautifully: nice brings in cake; kind goes to your manager and says "this person is doing exceptional work — put them forward for the next lead role." One action is easy and costs nothing. The other takes effort and investment in someone else's future.

Notice that kindness is consistently the hardest of the three. It requires you to be honest, thoughtful, and invested — all at the same time. Nice is cheap. Kind takes work. And unkind, whatever its short-term efficiency, almost always makes things worse over time.

Why kindness is a force multiplier

If kindness were just a nice-to-have — a moral aspiration but not a practical lever — it would still be worth pursuing. But the research and lived experience of high-performing teams suggests it's something stronger: a genuine force multiplier on engineering output.

The mechanism runs through psychological safety — a term from organisational researcher Amy Edmondson, later popularised by Google's Project Aristotle. Her finding, confirmed across teams in many industries, is that the single biggest predictor of a team's effectiveness is not the average IQ of its members, or the elegance of its process, or the quality of its tooling. It is whether team members feel safe to take interpersonal risks: to ask a "stupid" question, to admit they don't know something, to flag a potential problem before it's certain, to disagree with a senior colleague.

In a psychologically safe team, a junior engineer who suspects a bug will say so. An engineer who doesn't understand a design decision will ask, rather than spending three days building the wrong thing. Someone who spots a risky deployment choice will speak up in the review meeting instead of hoping someone else does. These are not dramatic acts of courage. They're the everyday information flow that separates teams that catch problems early from teams that catch them in production.

Kindness is what builds psychological safety. When you respond to a question without a trace of condescension, you make it safer for that person — and every observer — to ask questions in the future. When you run a blameless incident review, you make it safer for people to report near-misses next time. When you give honest, caring feedback and the recipient grows from it, the whole team learns that feedback is a gift and not a threat.

The practical payoffs compound quickly:

• Bugs surface earlier. When people aren't afraid to look incompetent, they flag half-formed concerns before they become real incidents.
• Learning accelerates. Questions get asked. Knowledge gets shared. Juniors grow faster.
• Attrition falls. People don't leave teams where they feel respected and invested in. They leave teams where they feel diminished.
• Decisions improve. Diverse perspectives actually get voiced instead of being self-censored because the room is dominated by the loudest voice.

Kindness in practice

Philosophy is useful until you need to leave a comment on a pull request at 4pm on a Friday. Here's what kind engineering looks like in the moments that actually matter.

In code reviews

Code review is probably the highest-frequency kindness test in engineering. Done well, it's one of the most valuable practices a team has. Done unkindly, it becomes a source of dread that makes people avoid submitting work, delay reviews out of resentment, or disengage entirely.

A few principles that consistently improve the dynamic:

• Understand the why before commenting on the what. Ask an open question before issuing a verdict. "I'm curious why this uses a polling approach rather than a callback — is there a constraint I'm missing?" invites dialogue. "This should use a callback" closes it.
• Label your nitpicks. "Nit: I'd use a more descriptive variable name here, but totally fine to leave." That single word tells the author: this is optional, I'm not blocking over this, and my bigger comments are the ones worth your real attention.
• Distinguish the code from the person. "This function does several things" is feedback about the code. "You always write functions that do too much" is feedback about a person. One is useful; the other is just unpleasant.
• Switch to synchronous conversation for long feedback. If you have six major concerns about an approach, a wall of comments can feel like a public dressing-down. A ten-minute call is kinder, faster, and more likely to actually resolve the issue.

You can also see the companion article on how to review code kindly for a deeper treatment of this topic.

In incidents

Incidents are a stress test for team culture. Under pressure and with real consequences, every habit — good and bad — becomes amplified. The kindest and most effective teams run blameless retrospectives: the assumption that people acted with the information and tools they had, and that when systems fail, the system — not the individual — is what needs to change.

This isn't about lowering accountability. It's about understanding that the same mistake rarely happens in isolation. Someone deployed a bad config because the deployment process didn't require a second pair of eyes. Someone missed the alert because the alert was one of forty that fired that morning. Finding the human to blame feels like closure, but it doesn't fix anything. Blameless post-mortems find the gap in the process that the human fell through — and fix that instead.

In meetings

Kind engineers create space. They notice when someone hasn't spoken and invite them in. They don't steamroll quiet thinkers with rapid-fire talk. They summarise decisions so that everyone, not just those who were most vocal, can leave with the same understanding. They follow up on commitments so that people's time and words are treated as meaningful.

In saying no

Counterintuitively, saying no clearly and early is often kinder than saying yes and under-delivering. When you accept work you can't complete, the person who asked spends time waiting and planning around a commitment that won't materialise. When you say "I can't take this on until the 15th, but here's someone who might be able to help sooner" — that's useful information that lets them make a real decision.

In glue work and sponsorship

Some of the kindest engineering work is nearly invisible: the person who writes the onboarding docs so the next new hire doesn't spend three days confused, the person who advocates in a planning meeting for a junior's idea instead of letting it get talked over, the person who tells a colleague's manager about a piece of work that deserves recognition. This is sponsorship — actively investing in someone else's growth and visibility. It costs relatively little and compounds enormously.

Kind does not mean pushover

This is the objection that comes up most often, and it deserves a direct answer. Kind engineering is entirely compatible with high standards — in fact, it requires them. The goal is not to make everyone comfortable; it's to make honest, constructive engagement possible. Those are different things.

Holding a high standard kindly means: being clear about what the standard is, explaining why it matters, and helping the person meet it — rather than simply noting that they've fallen short. "I can't merge this without tests because our coverage is the thing standing between us and the incident we had six months ago" is high-standards and kind. "This has no tests, which is obviously unacceptable" is high-standards and unkind. The outcome you want is the same; the path to getting there is very different.

Disagreeing well is also kind. When you disagree with a decision, saying so clearly, with your reasoning, is a gift — especially if you then commit to the decision if it goes the other way. What's unkind is passive disagreement: agreeing in the room and then undermining the outcome after it, or going quiet and letting a bad decision proceed because speaking up felt awkward.

Kind engineers also protect their teams. That sometimes means difficult conversations with stakeholders about unrealistic timelines, or pushing back on a demand that would burn out people who can't advocate for themselves in that room. That's not niceness — it's real care, exercised at some personal cost.

Being kind to yourself

Engineers who are unkind to themselves are frequently unkind to others. Chronic overwork, the refusal to ask for help, the need to appear competent at all times — these aren't virtues. They're exhausting patterns that erode judgment, create resentment, and make genuine collaboration harder.

Hero culture — the celebration of the person who stayed up all night to fix the incident, who singlehandedly rewrote the component, who is always available and always delivers — is seductive but dangerous. It makes the hero feel indispensable and secretly puts enormous pressure on everyone else to perform the same way. It also concentrates knowledge dangerously and makes the team fragile when that person is unavailable.

A sustainable pace isn't a sign of low ambition. It's what allows you to think clearly, give good feedback, be genuinely present in conversations, and keep doing good work for years rather than burning out in months. The engineers who are kind to themselves — who set boundaries, ask for help, admit uncertainty — tend to be the ones whose colleagues most want to work with. Vulnerability, as it turns out, builds trust. Performing invulnerability does not.

This also means asking for help early, not late. A question asked when you're two hours into being stuck is kind to yourself and to the person you ask — it gives them useful context and a solvable problem. The same question asked after two days of silent struggle is harder for everyone.

How kindness scales with role and team size

Kind engineering looks somewhat different depending on where you sit and how big the organisation is, though the core stays constant.

As an individual contributor, most of your kindness is local: code reviews, pair programming, how you respond to questions in Slack, whether you document the thing you just figured out so the next person doesn't have to. These moments are small individually and enormous in aggregate. A team where every IC treats the above as part of the job is a noticeably better place to work than one where they don't.

As a tech lead, you have disproportionate influence over the team's norms. The way you give feedback becomes the way feedback is given. If you ask questions rather than issue verdicts, others will too. If you celebrate someone who surfaced a problem early rather than criticising their mistake, you make it safer for everyone to surface problems early. Your single most valuable kindness investment is setting the culture of the team's interactions — and the fastest way to do that is to model the behaviour yourself, in every code review and every meeting.

As a manager, the levers shift. Psychological safety now includes: am I going to lose my job if I say this? That is a real concern for many people, and it needs to be actively addressed — through words, through responses to risk-taking, through what you do when people bring you bad news. A manager who reacts to bad news with frustration trains their team to hide bad news. A manager who responds with "thanks for telling me early, let's think about this together" trains their team to tell them early. The difference in outcomes is dramatic.

In larger organisations, kindness at scale often means creating structures that make kind behaviour the default: blameless post-mortem templates, explicit code review norms in the engineering handbook, 360 feedback processes that surface interpersonal patterns, promotion criteria that include how someone grows and supports their teammates, not just what they individually shipped.

Kindness compounds. Every honest review that lands well, every question answered without condescension, every blameless post-mortem that actually finds the gap — each of these is a small deposit into a trust account that the whole team draws on. Over time, that account is what separates teams that feel like places where good work happens from teams that don't. It's worth building carefully.

If you'd like to go deeper on one specific practice, the next article in this series looks at the craft of How to Write a Great Pull Request — which is itself an act of kindness toward your reviewers.