Be Kind
This article is about kindness at work, particularly kindness as part of building software (although much of it is relevant to all businesses). I’ve been meaning to write something like this for ages, and finally was given a kick up the backside by watching an excellent talk by Dan Terhorst-North. I really recommend the talk if you do anything in software.
What kindness is and isn’t
Before I get into the main part of my point, I think it’s worth clarifying what I mean by kindness. There are a few things that you might think I mean, that I don’t. I don’t think kindness is simultaneously biting your tongue and slapping on a happy face for fear of offending anyone. I don’t think kindness is the cork to help you bottle up your true feelings and wants, so they fester and turn sour. I don’t think it’s being passive and wishy-washy, so that the status quo can be maintained.
Instead: it’s a muscle you can use, that you can be active with to change things. It’s something that you can develop with practice. It helps you debug relationships, behaviours and attitudes.
That’s possibly a different view of kindness to the one you were expecting. What does that kind of kindness look like in practice? I will try to break that down in the next few sections. If I come across as preachy or condescending, I apologise. This is all intended as suggestions for you to consider, from someone who gets it wrong too often.
Kindness to colleagues
First, I will look at kindness to colleagues. There are often simple ways that you can make life better for people you work with. For instance, document important but tricky-to-remember things clearly, and put this documentation somewhere it can be found easily. This might be no more than drawing a rough diagram on a whiteboard, taking a photo, and then uploading the photo to the relevant part of a wiki.
This is part of a bigger area of kindness, which is communication. One way of describing communicating poorly is forcing the other person to work hard before they can understand you. Rambling and using jargon or long words and sentences make it hard for the other person to hold everything in their short term memory, which they need to do until they can parse it and make sense of it.
Are there processes where people just have to remember details each time, or processes where people often make mistakes? Consider writing a tool that automates some or all of that process. It doesn’t need to be fancy, with a lovely GUI and many configuration options. A simple script in your favourite language can often be enough.
Documentation and tools are both examples of kindness at arm’s length, where you create a thing for others rather than interacting with others directly. Most forms of kindness in my experience involve other people more directly.
Is there someone who monopolises conversations, who talks over other people, who belittles them or claims credit for their ideas? Standing up for others, particularly if you have relative power and status, can be a very direct and simple thing. Interrupting the interrupter with something like “I think that Chris was still going” can be all it needs sometimes.
You bear the awkwardness rather than the person who was originally interrupted. You need to be careful that you do this in a way that builds the interrupted person up, rather than portraying them as someone who’s helpless and needing to be saved. At the same time as reacting to what other people say, kindness to colleagues means periodically checking yourself: Am I the one doing the interrupting etc?
This brings me onto a thorny issue: giving negative feedback, i.e. telling someone you think they’ve done something wrong. For instance, what if someone continually interrupts others? To start, I recommend the approach: praise in public, criticise in private. Be very careful criticising someone in public, because it often doesn’t go well. By that I mean that it rarely results in the other person fixing the problem you’re describing in the criticism. Embarrassment or shame get in the way, triggering them to be defensive rather than receptive.
So you’ve decided to give some negative feedback, and you’re going to do it in private, now what? There are several tools that might help:
- Talk about this behaviour or this action and not you. This helps to stop the conversation being about core things like someone’s view of themselves and their value, and keeps it on more peripheral things that can be more easily changed.
- Think of you and the other person as colleagues stood side-by-side trying to tackle a common problem, rather than a confrontation between you and them. You’re not trying to win here; you’re trying to help someone to debug themselves and their relationships. This is why this is an expression of kindness.
- Point out your observations and feelings and then ask for their thoughts. For instance, “You seem to interrupt people often, and I’ve noticed people become less keen to contribute to conversations when they involve you.” They might be unaware of what you’ve noticed, or they might see their actions but not the consequences. Going straight in with you need to stop doing this bad thing you’re unaware of could force them to do too much catching up in a hurry.
Things can get even harder when the negative feedback is about their interactions with you. All the things I’ve described still apply, and I would add a couple of extra points:
- Try not to lash out in the moment. When emotions are raw it’s hard to navigate what’s already a tricky conversation. Wait until you’re more in control of yourself, but without so much delay that the conversation becomes “You made me feel like an idiot 7 weeks ago”.
- Your feelings are yours. It’s OK to state how you felt because of their words or actions – they can’t say “No you didn’t”. For instance, if you say “You’re late for meetings really often” the “really often” part is open for debate which can bog down the conversation. However, if you say “You’re late for meetings so often it makes me feel that my time isn’t important” then that’s a statement that can’t be attacked, which might help the conversation make progress.
There are other ways to show kindness to colleagues that are often easier than the tricky conversations I’ve just described. One is leading by example. This isn’t showing off, it’s putting your money where your mouth is. If you’d like code to be better structured, please structure your own code well before criticising others’.
Another way to be kind to colleagues is to point out what you see as their strengths and successes. People might think that they’re just doing their job, but e.g. they’ve highlighted a nasty risk to the system early in the development process, which has saved the team a lot of stress. This could extend to suggesting career paths they could follow, because you see potential in them that they don’t.
Kindness to colleagues can be a factor in fairly big picture things too. It might be that there’s some technical debt that you really want to get sorted out, or there’s some cool new thing you’d like to work with (maybe in part because it would look good on your CV). Working on the tech debt or cool new thing means that you can’t be working on something else.
Sometimes the tech debt or cool new thing is the right thing to be working on, but sometimes your organisation doesn’t have that luxury. Money or deadlines are so tight that everyone needs to focus on what will bring in money in the short term. This will help the company to survive, and reduces the chance of pay freezes or cuts or people losing their jobs. (I’ve been on the wrong side of both of these, and they’re not fun.)
This is a tricky issue, because you can err the other way too, where failing to fix problems or invest in new enabling things means that the company will grind to a halt in the future. I’m not advocating for never raising tech debt or new things. What I’m advocating for is for accepting that there are other forces at work, and you might not know all the details behind why your proposal has been turned down. This means you might need to hold your nose around the smelly code for longer than you’d like, but this might be for a good reason (you and your colleagues’ immediate future).
Kindness specifically as part of management is several articles on its own, so I won’t go into that here as this article is already too long.
Kindness to users
We know as users of software that it’s frustrating when they’re buggy or lacking important features. We should be kind to our users by keeping them in mind as we work, to avoid inflicting that sort of frustration on them. Are we making someone’s life even slightly better with the code we’re writing?
Kindness to users shows up in many places, including product management, user experience (UX), programming and testing. I’ve already written about those elsewhere (click on the links to see lists of relevant articles) so I won’t go into any depth here, but underpinning it all can be kindness.
Kindness to yourself
The final recipient of kindness I want to discuss is you, i.e. being kind to yourself. There are a couple of main areas to this – your interactions with others, and how you treat yourself.
Part of being kind to yourself is setting and enforcing boundaries on what other people can do to you. This is another balancing act – on one hand you want to avoid being a doormat (this is the bottling up your emotions and needs version of kindness I rejected earlier) and on the other hand you want to avoid putting unreasonable demands on others.
However you decide to perform the balancing act, there should be boundaries and you are the first port of call in enforcing them. This can lead to the awkward conversations I mentioned earlier, where you’re giving people bad feedback.
Another balancing act that’s important but hard to pull off is how you view your skills and behaviours, and then what you do about changing or improving them. I think it’s healthy to realise that we’re all imperfect and so some kind of self-awareness and self-improvement are a good idea. However this can go too far, where we have low self-esteem or treat self-improvement as a stressful full-time job that should occupy all our time outside our day job.
I can offer no easy answers, as I think there are none that are useful. I would like to point you to wisdom from Don Greene, taken from the podcast Art of Manliness:
I call this the Julliard Syndrome. When I was at Julliard one of the exercises I would have them do all in the same time in rehearsal room, take out their instrument and play the most challenging thing they could play in the midst of all the chaos, people playing different instruments, different pieces. Have that go on a couple minutes, and I say, “Okay, write down all the things that you’d say to yourself when you’re doing that.” They’d write it out and for these beautiful young bright students who played beautiful music, when they read them aloud it sounded like sailors. Cursing.
It was amazing, and they started laughing. We all started laughing. Then I made three copies of each, I would have one of them sit surrounded by three people reading what they were saying to themselves like, “You idiot, can’t you play? You sound like crap.” Everybody started laughing, and I said, “That’s what you’re doing to yourself. That’s how you get to Julliard, not by being sloppy and ignoring it, but after you reach a certain level of competence, put the stick away and take out the carrot. Positive reinforcement works much better than negative reinforcement.
We use it on everybody else, but not ourselves, and this is the major shift I had these students do that, you know if you want to live a happy life, stop with the nonsense and criticism and learn how to be positive reinforcing with yourself like you do everybody else. That’s it. It’s pretty straightforward. After about a week or two of writing it out, the list gets shorter and shorter and you’re just more positive reinforcing with yourself or mentally quiet. You don’t need all of that. You don’t need that noise.
One aspect of software development that makes the balancing act I mentioned hard is the pace of change. There seems to always be a new thing to read, watch or listen to. There’s always a new language, tool or framework to use, a new architectural approach to know, a new skill to practice etc.
I suggest that you split the world of things to learn into two – strategic and tactical. The strategic things are fundamentals that will last, and the tactical are things that will become obsolete more quickly. The fundamentals are things like data structures and algorithms, the basics of how relational databases and common communications things like HTTP and REST work, the difference between OO, procedural, functional and declarative programming etc. They are also how to test software, how to communicate, how to solve problems, how to manage your time etc. The tactical things are things like programming languages and frameworks, tools like IDEs etc.
To get and keep a job you will need a blend of strategic and tactical things – just strategic or just tactical won’t be enough. However, strategic things are more like to stay useful at that job or when you move to a new job, so it’s worth identifying any gaps you have in the fundamentals and weighing them against learning yet another tool.
Often you can identify sets of rival tactical things, such as JS presentation-layer frameworks or ORMs. Knowing one member of each set is usually more useful than concentrating on collecting all of one set at the expense of knowing even one member of other sets. (Knowing two JS presentation-layer frameworks and no ORMs is likely to be less useful to you than knowing one JS presentation-layer framework and one ORM, for instance.)
Competing considerations
By now you might be feeling overwhelmed. How can I be kind to all my colleagues, at the same time as being kind to users and to myself? It seems that pulling all of this off is impossible.
I don’t have any easy answers, but I do have some analogies that might help. Trying to satisfy competing constraints is something that engineers wrestle with all the time. How can we design a car that is roomy, easy to park, safe and energy-efficient at the same time? How can we design a distributed software system that is internally consistent, highly available to users, and tolerant to breaks or partitions in the network connections between its parts?
The fact that it’s impossible to design a car that ticks all possible boxes doesn’t mean that no-one designs and builds any cars. Similarly, distributed systems exist despite each having to make compromises over their quality attributes. So I suggest that you show kindness to yourself at the meta level, by allowing yourself to mess up in some way while you attempt to flex your kindness muscle.
Final thoughts
One way of summing all this up is the Golden Rule: do to others as you would like them to do to you. This can be adapted when thinking about kindness to yourself: treat yourself as you would treat someone you know and care for. Some of the time this involves tough love, but it is also a large amount of forgiveness and support.
There’s a lot of overlap between applying the Golden Rule and UX, which is something I hope all software people think about even if they don’t work on things with GUIs. Both involving putting yourself in someone else’s shoes, and letting the knowledge you gain from that inform your actions.
Finally, I see kindness as part of leadership. It’s not the part of leadership that depends on authority or position – anyone can do it, regardless of position or job title. But it’s a tool you can use to change the people and relationships where you work.