Kind Engineering
How To Engineer Kindness
by Evan Smith ([email protected])
And kindly edited/reviewed by Cathy Naughton, Fionn Kelleher,
If you’re more of a audio person, this article is adapted from a talk I did of the same name.
Like my talk, this post really only skates by the benefits of being kind. The rest of this post will focus more on how to be kind and encourage kindness with practical advice and tips. If you’d like to read more about the benefits, I would recommend the Further Reading section at the end of the article.
What Is Kindness?
“Kind is about being invested in other people, figuring out how to help them, meeting them where they are.”
— Tanya Reilly, Continuous
Kindness is a concept we can understand but find hard to define, which is why I really like the above definition from Tanya Reilly, Principal Engineer at Squarespace. Being kind is about getting invested in other people, it’s about meeting them where they are. It’s about putting yourself in their shoes and taking them, their emotions and their background into consideration as you try to help them.
Everyone’s got different words for it (e.g. Techstars calls it “Give First”) but when you reduce it down, it’s about empathy, good communication and being honest with yourself and your colleagues.
It isn’t a one-size-fits-all bandage you can whip out and use to magically solve all of a team or organisation’s problems. Kindness is individual and it takes time to build the type of relationship and trust that’s required to be kind - and not just nice.
Be Kind, Not Just Nice
Niceness is equatable to politeness. It’s about your external demeanour; about being agreeable and friendly. On the other hand, kindness is about taking a more active role in someone and being invested in helping them — it’s about the idea of meeting them where they are to help them.
“Nice brings in cake, and we love them for it. Keep bringing in cake! But Kind goes to your manager and says "hey this person is doing great work, consider them for the next lead role", and you never know it happened.”
— Tanya Reilly, Continuous
Give & Take: There Are 3 Types Of People In This World
To explain the benefits of kindness, I really like the book Give and Take by Adam Grant. It talks about the 3 types of people in the world: Takers (who take more than they give), Matchers (who give as much as they take), and Givers. The book talks about the benefits of being a Giver in the world and how to do it sustainably.
Givers, when done sustainably and for the right reasons, end up:
Being more productive
Creating more meaningful networks/friendships
More likely to receive help themselves
Being more successful
Happier
Honesty
Honesty creates trust and constructive criticism. It’s an important part of learning and getting help. It’s also the foundation for better understanding people, where they come from, what they’re like and what kind of help they may need. Honesty is a cornerstone of meeting people where they are to help them.
Being At Work
Okay, so this may be mildly controversial as we’re always talking about a separation of work and person BUT! one of the things I recommend is being more than “just professional” and bringing your rounded self to work. Care about the people you work with and share more than just your work self. We’re fully rounded people with interests and hobbies that form a large part of that, and it's an important context people may need to understand and help us.
It’s the same for your colleagues. The story that led them to today is going to change how you know if they’re in trouble or how you soothe them when they’re upset. Without knowing someone beyond just their productivity and output, you’re never going to be able to accurately tell whether they’re not doing well, whether they need a helping hand or that they trust the feedback you’re giving them.
Being open about your life is humanising and helps build trust. It requires a bit of vulnerability on your part and that can be scary but it’s super worth it. It helps to dissolve that barrier you might have made between work and your personal life. I’m not saying you should totally integrate the two; you should have very definite boundaries of what you’re willing to talk about to make sure you are comfortable.
I really want to emphasise that this is about better understanding and interacting with people, not about giving yourself totally to the company. It’s about being open and vulnerable with your co-workers while also being clear with your boundaries. It’s about being a person who acknowledges that we work to live, and not the other way around.
Building this trust is important because it’s going to give you the credibility to do something very important: challenge people directly. People often interpret this as being “brutally honest” but it’s not. The book Radical Candor talks about the need to challenge directly (honesty) and care personally (empathy). Without honesty, the feedback isn’t constructive or helpful. Without empathy, the feedback isn’t meeting them where they are to help them.
- Be more than “just professional” and bring your rounded self to work.
- Be open about your life and be human to help build trust.
- Challenge people directly but care personally.
Be Honest… When It Helps
White lies aren’t evil but they don’t help people grow. There is a skill to be learned in giving good feedback (though I’ll give advice on that at the end of this article), but you should strive to always be honest and helpful with your feedback and with your peers… when it’s helpful. This is another point about caring personally when you’re challenging people.
For example, if someone’s leading a meeting and trying to persuade the room to adopt a new architecture but it doesn’t go well, the unkind thing to do for them there is lie and say “good job in the meeting!” You’re probably trying to boost their confidence and encourage them to keep doing those meetings but what happens when the participants turn around and reject the idea from the meeting? Now they know the harsh truth of what happened, they’re thinking about what you said and wondering if you were lying to them, and it’s undermining the credibility of your feedback in the future.
Instead, you should be honest and provide what went well, what went badly and something that could be done differently in the future.
“Your answer to the question was a bit rambly and you missed the opportunity to convince the team about your idea. But it is a good idea so practice your elevator pitch and you’ll get it next time.”
You’ve been honest about what happened, praised them for the things that did go well and given them a clear way to improve.
- White lies aren’t evil but they don’t help people grow.
- Be honest, praise good work and give clear ways to improve.
Async Communication:
Code Reviews
Change is the only constant in tech, so it makes sense to master the communication around it. One of the most powerful asynchronous tools of change is a Pull Request/Code Review. It’s important we don’t dismiss these as a checkbox-ticking exercise. Instead, you must drill down until you fully understand the change and the context behind it.
Really, I want to talk about how to deal with all asynchronous communication, but through the lens of code reviews as a common example in tech. This information is generally applicable to any async comms tool you use.
Understanding The Why, Not Just The How
To start with, you need to understand The Why of a change and it’s important your tone going into this is one of curiosity and not interrogation or condescension. A bad tone is going to make someone defensive, and that’s not going to make them want to learn and grow.
Try to understand more of the Why of a change, and not just the What and the How. You need to get into the weeds a bit to understand better. Why is someone deleting this piece, or reusing this piece or why have they put this little utility function here? Put yourself in their shoes a bit and think about why are we making this change? Why are we doing it like this?
As part of digging deeper, don’t assume malice or ineptitude. Assume you might be missing something and ask for clarification rather than correction. Don’t jump in guns blazing with comments like “this is wrong” or “we do it like this”. Be open to the possibility that you’re missing something and that your understanding here is flawed.
Ask open-ended questions instead of making strong or opinionated statements. Being open-ended about your feedback, about what you’re wondering, gives people an opportunity to fill in that missing gap of understanding you might have. It gives them a better chance to explain The Why to you. This is about meeting them where they are to help them, not dragging them kicking and screaming to whatever “standard” the team has.
- Try to understand more of the Why of a change, and not just the What and the How.
- Don’t assume malice or ineptitude.
- Ask open-ended questions instead of making strong or opinionated statements.
Nitpicks
“Nitpicks are unimportant comments, where the code could be merged without even addressing them. These could be things like variable declarations being in alphabetical order, unit tests following a certain structure, or brackets being on the same line.”
— Gergely Orosz, How to Make Good Code Reviews Better
For aligning someone with the team standard, nitpicks are your friend. They’re useful for calling out changes that would be nice but aren’t required for the code to be merged - for example, code style changes or language idioms.
It’s important when calling out a nitpick that it’s clearly labelled as such. I like the simple `nitpick:` prefix before a comment. This way, those comments become optional and people can skim over them if they’re too busy or not in the right mindset for that feedback right now. Deadlines force us to make trade-offs with our code quality and it’s much kinder to clearly label something “you can skip this” than forcing the already-stressed person to filter and sieve through those comments themself. Call it a nitpick and if it’s not addressed, add a ticket somewhere to come back to it.Nitpicks clearly label the level of attention required by a comment so that if they’re in the mood, they can rifle through docs and understand better the change you suggested. If they’re not, it’s very easy to make the change or ignore it and move on.
Secondly, nitpicks may suggest a larger problem with your tooling. If you’re making a lot of the same nitpick comments, consider adding/changing your pipeline to include linting. It’ll help align code to your standards automatically before it’s reviewed and people are often more open to the very tedious kind of feedback of nitpicks from automation, more than they are from people.
Mary leaving a hundred nitpicks on my PR? Goddamnit Mary. Python’s Flake8 linter leaving them? Goddamnit Flake8. We’re okay with animosity towards the tooling, not so much when it comes to Mary.
- It’s important when calling out a nitpick that it’s clearly labelled
- A lot of nitpicks may suggest a larger problem with your tooling.
Sync vs Async
So, I know I started this by saying Pull Requests were one of the most powerful asynchronous tools out there but it’s important you understand where their limits are. If there are a lot of comments on someone’s request, you should try and switch to a synchronous form of communication and have a conversation about it. There’s likely something you’re missing, a piece of context that may be key to this that isn’t present, and doing the back-and-forth over a pull request is painful and slow.
Reach out to the author directly. People much prefer long conversations that may include a lot of criticism to 1) happen in real time; and 2) happen privately. We may not always think it but pull requests on Github (etc.) are public, even if it’s just to your team or your company and a lot of feedback on a request (regardless of how kindly your tone is), can feel a little humiliating - it can feel like you’re on display for everyone to see, if they choose to watch.
Understanding when you need to switch will come with time as you get to know a person’s preferences. However, it’s better to default to a private form of communication for conversations like this at the start and be cautious about how someone will feel. This is part of that theme of meeting them where they are to help them again.
- If there are a lot of comments, try and switch to a synchronous form of communication.
Psychological Safety
Psychological safety is an easier topic to understand than it maybe sounds at first. Boiling it down to just one question: How safe do you feel in your job calling out problems and fixing them? All kinds of problems! Not just technical, but about inclusivity, comfort and blame. The last decade has seen a shift from top-down management to empowering employees with the ability to solve their own problems.
Our feeling of safety is all-encompassing and feeds into every aspect of our work. Not feeling safe can make it hard to contribute in meetings, provide solutions, speak out against future mistakes and may make you feel isolated or unhappy. It’s incredibly important that as the business world evolves, we pay more and more attention to the psychological impact our practices and processes impose on people.
Encourage Feedback
The first step to recovery is admitting you have a problem, start by being the first to ask for feedback from your team/peers. Especially negative feedback. Make it clear you’re asking for it and people should be open and honest. This is all in an effort to build relationships and counter the “I can dish it out but I can’t take it” problem that can come up. By seeking out criticism, you make yourself vulnerable and more open. It builds up a rapport with people and makes them more amenable to criticism from you later. We’ll continue to talk about this more in-depth later on.
A really simple structure I like to use for all kinds of feedback is the same one used in sprint retrospectives: What should I start/stop/keep doing? Which is basically: what went well? What went badly? What can we do again in the future? After a project/quarter ends, or after a meeting or a presentation. Take some time to gather feedback. Take time to listen, process and grow a little. Thank people for their criticism, make them feel appreciated for what they’ve shared because it was probably hard. If you’ve ever had to give tough feedback before, you know what an anxiety-inducing experience it can be. Show people you care by graciously accepting what someone has to say and giving it the respect it deserves.
- Be the first to ask for feedback from your team/peers.
- A really simple structure of feedback is: What went well? What went badly? What can we do again in the future?
Be Inclusive
As the world feels smaller and smaller everyday thanks to technology, embracing diversity is probably one of the most important things you need to do. Be open and aware of people’s backgrounds, history and personal preferences. It’s all about helping people by meeting them where they are, where they want to be helped - being kind is not about “meet me halfway”.
Keep an eye out for people who maybe don't contribute as much in meetings or in documents and try to find ways to give them a voice. It might be just prompting them for feedback in the meeting or maybe you need to re-evaluate how people contribute entirely. Be open to different backgrounds and different life experiences by talking to them and offering to cater to their preferred style of suggestions and communication. Not everyone feels comfortable being outspoken in a meeting so maybe sharing documents beforehand or providing an anonymous suggestion form would give them space to make their opinion heard.
Give people a voice by letting them express themselves in whatever format they feel is right. And then bringing those ideas to a central point/meeting/document/dance-off. Inclusivity, in particular, is key to making sure that you meet people where they are to help them.
- Be open and aware of people’s backgrounds, history and personal preferences.
- Keep an eye out for people who maybe don't contribute as much in meetings or in documents and try to find ways to give them a voice.
- Give people a voice by letting them express themselves in whatever format they feel is right.
No Blame
Often an individual failure is actually a failure of either process, environment or workflows. Assigning individual blame breeds distrust and caution, the opposite of a psychologically safe workplace. A former manager used to say that we put you in the position to make that mistake or push that commit and that is why the team takes ownership over it.
We succeed together, we fail together.
Being blameless doesn’t mean you can’t make people accountable for ongoing issues. Instead, it means that you don’t scapegoat every mistake on the junior employee who wasn’t given enough training, or who made a bad assumption, or who was just the messenger for a bigger problem. When something goes wrong, you have to look at the whole picture and understand the decisions, the assumptions and the past experiences that all fed into that one incident.
In the end, by shifting away from finger-pointing, people become more comfortable and often they feel safer with pulling apart processes, workflows or code to help prevent this from happening again in the future. We don’t want to hurt people, we don’t want to be the bad guy, so we shouldn’t put people in a position where the outcome of a report could negatively affect one of our friends - you’ll end up with biased, possibly falsified or deliberately watered down conclusions. We want honesty and the best way to build it is to show people that they won’t be fired for being honest.
- Often an individual failure is actually a failure of either process, environment or workflows.
- We succeed together, we fail together.
Turn Failure Into Learning
On a similar note, every “failure” or incident should be celebrated as an opportunity to grow and learn. It's important to recognise that failure is not absolute. It's not the end of the world, we fail, probably dozens of times a day. We don't always recognise it, but we learn from it, and do it better the next time around.
It’s okay to fail, that’s how we get new ideas. To promote innovation, we need to encourage people to take risks and experiment - and feel safe doing it.
Similar to the feedback sessions, you can use that same (basic) framework of three questions to pick apart when things go wrong. In fact, in the SRE world, it’s pretty common to publish your findings from those conversations in the form of postmortems.
“The cost of failure is education.”
— Devin Carraway, Microsoft Engineering.
- Every “failure” or incident should be celebrated as an opportunity to grow and learn.
- To promote innovation, we need to encourage people to take risks and experiment - and feel safe doing it.
Feedback/Criticism
There are two constants in life: death and feedback. It’s a skill we will need often and it’s a shame we never get taught how to give, and receive, good feedback. Hopefully this section will help give you some practical advice on giving and receiving feedback.
In General For Both
I’d like to start by reiterating some advice: be the first to ask for criticism, don’t start by dishing it out. It’s important that people understand it’s a two-way street and that there’s an evenness when it comes to feedback. The last thing you want is an image of being overly critical undermining your credibility and good feedback.
Don’t make it personal. The feedback should be about a piece of work or some actions taken, and not framed as a problem with the person. It’s not a personal failing to make mistakes and we are not defined by our work, so any feedback should be about something that has occurred and, if criticism, the clear actions that can improve it.
When giving feedback/praise, try to be as specific and thorough as possible. With criticism, it makes it easier to analyse what went wrong and how it can be approved. Similarly, with praise it makes the feedback feel more genuine and earned - specificity shows a level of attention that people really appreciate with praise.
While not always possible, if you give someone critical feedback, try to also offer a solution or some advice. It’s much easier to start improving on something if you have a clear first step/goal to leapfrog from. Sometimes problems don’t have clear solutions that you can see (such as problems with your manager or with “bad vibes”) but it’s important that you at least try to find something that would have improved the action that led to the feedback.
- Be the first to ask for criticism, don’t start by dishing it out.
- Don’t make it personal.
- When giving feedback/praise, try to be as specific and thorough as possible.
- If you give someone critical feedback, try to also offer a solution.
Receiving
This is the bit I’m always surprised people don’t care about more: understanding how to receive feedback. It’s not just: sit there and nod. It starts with understanding your own feedback preferences. Are you okay with criticism in public? Do you prefer criticism in writing/slack? Do you prefer it face-to-face? Understanding your own communication preferences — making sure everyone else understands them — will make you more comfortable hearing negative things and it will set you up the best to grow from them.
Secondly, you’ve got to listen, understand and then Thank the person for the feedback. Giving negative feedback is hard. It’s important we acknowledge that first and then honour the feedback by trying our best to listen and understand. Even if eventually you decide that the logic is flawed or that you don’t have good faith in their argument, you won’t get to either of those conclusions unless you perk your ears up and work through what they’re saying.
When you first get the feedback, if you’re like me, you’re going to feel a little defensive. It’s cool, it’s natural (I think). So you should always remember: don’t react in the moment, take some time to gather your thoughts and process the feedback. Take just 15 minutes to go outside, go for a walk or make a hot beverage of your choice. It’s important you give yourself time to work through what’s been said before you come to any conclusions.
Finally, if applicable, ask for clarifications and/or examples about the feedback. Not everyone’s going to give you the logic or specificity you need to properly grow from what they said. It’s okay to go back and try to get that information from them. It’s also going to feed into your relationship and credibility with that person because it shows you’ve listened and that you’re eager to learn.
- Understand your own feedback preferences.
- Listen, understand and then Thank the person for the feedback.
- Don’t react in the moment, take some time to gather your thoughts and process the feedback.
- Ask for clarifications and/or examples.
Giving
When it comes to giving criticism, it’s a daunting task but there are just three elements you need to keep in mind when preparing it.
Emotion: Take the listener’s emotions into account, not your own. This is about removing your personal feelings about the situation from the equation and understanding their emotional state. This is where all that trust and relationship building comes into play; in understanding your coworker and how they’ll react. Be patient. And if the feedback is about an emotion they made you feel, don’t be still living in that emotion when you give the feedback. Otherwise, it’s going to make you defensive, and then cloud and undermine what you have to say.
Credibility: Demonstrate expertise and humility. The recipient is going to need to fully trust that what you have to say is credible and from a place of good faith. You may have noticed, I mentioned credibility a lot throughout this and here is where that comes into play. You need to show that you know what you’re talking about with clear advice and tips, as well as calling out what went well.
Logic: Show your work and how you reached the conclusion. This is probably the easiest bit. Be specific about why you’re giving this feedback and clearly show your workings so that the recipient can understand if there’s any flaws or missing context. Being very good at the logic part of giving criticism will also feed into building credibility in what you say going forward.
- Remember the 3 elements of giving feedback: emotion, credibility and logic.
- Take the listener’s emotions into account, not your own.
- Demonstrate expertise and humility.
- Show your work and how you reached the conclusion.
Further Reading
Briefly, here are some books/articles I’d really recommend if you want to learn more about what I’ve said before.
[book] “Give and Take” — Adam Grant: Talks about the benefits of giving, as well as studies and stories about how to be more sustainable and smart about how you give.
[book] “Radical Candor” — Kim Scott: Is centred around honesty and good feedback. Candor goes beyond just feedback though and is a much deeper, kinder topic than I was led to believe by the CEOs quoting and misusing it.
[article] “Being Glue” — Tanya Reilly: A wonderful speaker who understands the human element of work and Being Glue is an amazing talk that goes into the work between the work that often goes unnoticed - and is often a kindness in your teams/org.
[article] “Getting Feedback” — Allison McMillan: A great article on receiving feedback and how to do it well.
[article] “Changing Company Culture Requires a Movement, Not a Mandate” — Sarah A. Soule & Bryan Walker: A lot of what I talked about requires you to make some cultural shifts within your team/org and this lays out clear advice on how to do that well.
[article] “Psychological Safety and the Only Pyramid Scheme That Works” — Me but I swear it’s good! This is an introduction to psychological safety and how I first learned to understand it. Although Maslow’s Hierarchy is no longer how I’d choose to explain this (probably opting for the B.I.C.E.P.S. framework instead), it leans more on using the pyramid’s individual components for examples and not the hierarchy (which is the flawed bit).
Conclusion
Finally, we get to the end of this long read and together we have learned that kindness is about 3 things:
Communication
Honesty; and
Safety
So I’d like to leave you with a simple question to get you thinking about kindness in your own teams, in your own companies:
