Kind Engineering: How To Engineer Kindness by Evan Smith

good morning everyone for me it's quite early it's approaching about 8 a.m so

apologies if i'm groggy but i've chugged two copies at this point so hopefully i'm awake um today we're my name is evan for first of all i am evan and today we're going to be talking about kind

engineering and before we hop into it i'm going to spend a little bit of time to explain why i did this talk um what it's about and what the structure will be like

today uh there's a link down there in the left those are my reference slides so i believe in the in the concept of you can either listen to me speak or read my slides so

these are slides with speaker notes embedded into them into like a slide before each real slide and if you want to download them at the start but there'll also be a link at the end and i believe devops pro also has a way

for you to download them themselves um so why did i choose to do this uh if you read my the blurb for this talk you probably have an idea so software engineering is this

environment that is rife with worrying stereotypes like the brilliant jerk the 10x engineer the peter principle they're all really kind of like negative stereotypes and i kept coming back to this question

for how do i be a kind person and a kind engineer and encourage kindness in engineering specifically because it seems like those are two things that don't go

together normally kindness engineering so for the last couple years i've been exploring what it means to be a kind engineer and it's called different things in different circles

but ultimately it comes down to the fact that people who give more unconditionally make themselves happier their teams happier and our company's happier so today i'm going to be sharing some

practical tips on how people can become kinder engineers and through that there will be six sections so there'll be an intro which is a bit about me a bit about kindness in general and then there'll be four

sections which is kind of like the meat of the the the talk it'll be about code reviews it'll be about honesty in the workplace it'll be about psychological safety

safety and it'll be about um giving and receiving feedback and i will prepare you because it's still quite early here so you may hear kids in the background you may hear

dogs running down the stairs and you may hear a cat who is very upset with me because i have taken them out of the room to do this talk so please bear with me but without further ado we'll hop right

into it so a bit about me as i said i am evan i'm from ireland uh i'm just moved back from ireland actually this week so this slide is

unfortunately out of date by about a day i'm a site reliability engineer with a company called solidmate i'm a massive nerd and i think or at least people have told me

i'm a kind engineer um but what does kindness mean so kindness to describe it i really love this quote from tanya riley um who works at squarespace

her talk continuous is a great talk but i really love this excerpt kind is about being invested in other people figuring out how to help them and meeting them where they are

and you're going to see today that that last bit meeting them where they are that's a recurring theme that comes up again and again and again i'll highlight each time it comes up in the talk because it comes

up a lot that is the crux of what kindness is it's about finding out how to meet someone where they are and not asking them to meet you halfway not asking them to meet you

where you are to help them it's about meeting them where they are walking them all in their shoes going to them and there's a difference between being like kind and nice i mean you should be both be as nice as

much as possible but nice brings in cake and we love them for bringing in cake everyone should keep bringing in cake i love cake but kind is the kind of person who goes to your manager and says hey

this is per this person is doing great work consider them for the next lead role or consider them for the next project um and you never know what happened it doesn't

it's something that doesn't implicitly benefit them it's something they have done for your benefit so i imagine the question you all have at this point is what has kindness ever

done for me and i really love this book by adam grant and it's called give and take um and the the it shows it divides the world into like

three different types which are givers who give more than they take takers who take more than they give and matchers who give as much as they take or they take as much as they give depending on your

glass half full kind of attitude and it has a lot of studies a lot of anecdotes a lot of stories that prove that um givers generally end up more productive they create more

meaningful networks they're more likely to receive help they're more successful they're happier in general and they bring that to the rest of the company

so the first section we're going to cover today is probably the most uh common thing you will do in engineering it's one of

the most powerful asynchronous forms of communication we have in engineering and it comes up a lot so it's really important that we nail the the tone in code reviews that we nail how to be kind and code reviews

because they're probably the thing we will communicate with our colleagues the most with so it's important to begin with with the tone

so you should be trying to understand more of the why and not just the what and the hell of a change understanding the reasoning that went

into the change the motivations why someone is doing it you shouldn't assume that people are doing it out of malice or ineptitude when something goes wrong or you have to correct something

something people don't get up in the morning and choose violence it's just not true people do things because they think it's the right way to do

um you should also a a good method for kind of like sussing out what motivations are in a code review is you should ask open-ended questions instead of making strong or opinionated statements

so instead of making a statement about this is true and we do it like this or we do this or that ask more why questions ask more like

um what if questions like if something is done differently to how it's normally done maybe be like ask them a what if question about like the scenario

it's meant to prevent if this code doesn't scale ask them what would happen if um one of the servers went down uh how would this code affect the rest

of the fleet or um there's so much you should be concentrating on when it comes to open-ended questions um and make questions instead of

statements it's a it's a really easy switch to flick instead of like telling someone in a review that um you have to do this or you have to do that or this is wrong or this is right

just ask a question instead it makes people less defensive it means they're more open to feedback it means they're more open to your change and understanding and learning uh and the the final thing i want to say is

that you should try to assume that you might be missing something try to ask for clarification rather than correction this feeds into the open-ended questions because it gives people room

to um clarify the situation and clarify um why they did this why they chose to do this what happened with it instead of

you trying to correct them and a small part of the code reviews that i really wanted to highlight was nitpicks because nitpicks come up a lot so they're if you don't know what they are they're unimportant comments you

could merge the code without addressing the nitpicks and that's the definition of them they're tiny little things that help people learn kind of like on a on a smaller scale on a

cumulative scale and but they're not necessary for the code to run and two things you can do are you can clearly identify and call out your nitpicks

so you make it very clear that the message is this is a nitpick it's not something you have to spend too much worry about um and two if there are a lot of

nitpicks it may be sign of a larger problem such as with tooling process or standards you can add automation such as like linting or formatting to your um

to your code pipeline to avoid having to do a lot of nitpicks there's probably a bigger problem at play here if you have a lot of nitpicks

i would say more than five is a lot of nitpicks and so i said that this was an asynchronous communication tool

and it's important to understand when that should stop being asynchronous and depending on your setup it may not be the cost of becoming synchronous um

maybe more or less depending on your organization um but it's important to understand when to sit down and talk to someone either through im or through

um face to face on like a web call or in a meeting or something so if you have lots of questions and you should reach out to the author directly because sometimes some people don't like a lot of public criticism

i know um personally like um i've found it quite hard when i'm new at companies and some people are like well these don't meet our standards um and you get like a lot of comments and it can feel a little demotivating it

can it can tear you apart a bit because like github or gitlab or bitbucket or whatever you have um is sort of a public platform within your company within your teams

and we don't think of it as a public platform because it's gated between behind like a vpn or behind a login or something and but it is public to all your colleagues and it can suck to feel kind of like on show for

your technical skill for your for your um ability as an engineer so sometimes it's more kind or it's often more kind to just sit down with someone face to

face and understand that like maybe they don't like public criticism and that like a lot of nitpicks kind of puts them on a very defensive standpoint

and two a lot of questions can indicate that there's a misunderstanding here you might be speaking past each other like just just missing one piece of kernel of information and it's gonna be

a lot quicker to to talk uh through it rather than through messages on github especially because um it's very hard to imply the tone of what someone says through github

we try and mitigate that through asking open-ended questions and being more open in our language but the the unfortunate truth is you can't

there's no way to signify tone in a in a text message we have tried the internet has tried many times to do it an emoji help let me tell you emoji gives help but it's still quite

hard it's still quite hard to interpret so and that brings me to my third point which is that along back and forth of questions and answers are exhausting and talking

will be much quicker if you have a long thread on github especially one that's quite detailed it's probably time to sit down with

the author of the pr and talk it through and understand it a bit better understand the why a bit more and a part of understanding the why is uh

what feeds into that is honesty honesty in the workplace so honesty is a is a bit of a it's a tough one because you want to be honest but you don't want to be mean

and if you've ever read the the book radical candor it goes into a lot of the material i will talk today about feedback at the end but honesty there's more to

honesty than just the communication honesty is about being at work it's about being yourself at work it's about bringing

yourself to work um and you need somewhere that's going to treat you well based on who you are genuinely and not just who your work fursona is

um you should try to be more than just professional it doesn't mean you have to invest more in the company and like treat it as a family that's not what i mean i mean share your hobbies share your

interests and care about people and share more than just uh your work self encourage everyone to do the same with you learn more about them learn more about what they do in their spare time do they

hike do they play video games do they read a lot what do they like to read is a smiley fan fiction you know stuff like that um where it's it's important to understand

that people are not just this one-dimensional work engineer they're not they're not these like one-dimensional people

they have multiple we we we are infinite and we should try to understand and take that into account when we're at work um and a part of that is challenging

people directly uh when you disagree with something uh don't like don't just focus on the negatives and be sure to admit when you're wrong be humble hum and show humility

um but you should when you have a disagreement challenge people directly go to them directly and be honest with them up front you don't want them hearing it through a side channel you don't want them hearing

it through someone else that is going to degrade your relationship with them and you're poor with them and this is about building up a rapport it's about understanding who they are

and them understanding who you are and trusting you a bit more it's about trust and the last thing i want to mention is that

um often it comes up that like you know often it it's kinder to lie it's not white lies aren't evil but they don't help people grow and it's one of those things where you

don't want some you don't want to admit to someone um that you don't want to say like you did a great job and then them here

that they didn't which brings me into the next section being honest when it helps so um you shouldn't be honest relentlessly you shouldn't be brutally honest

that's not going to be kind that's not going to be helpful it's going to wear people down it's going to mean they're not going they might trust your feedback but they're not going to

like that you haven't put any empathy into your feedback and so there's a difference between nice and kind i had kind of mentioned it at the start but here's a clear example so you went into a meeting

and your colleague was presenting a new topic maybe their a new architecture design will say and they it didn't really go well

people tuned out no one really listened they got the okay at the end but you know it wasn't really successful so um what happens is afterwards they come to you and they're like hey how did i do in

the meeting they were like oh you're like good job in the meeting that's nice that's a that's kind of like a white lie uh it's it's something that like you want them

um you want them to do more talks so you're kind of like being um i think the term is ruinously empathetic you're using too much empathy and you're saying good job in the meeting and you're lying

to them because they didn't go well it wasn't a good job so what happens if the the committee sits down and they think well actually we don't really like this idea

um and then that person finds out that okay why did evan tell me that i did a good job in that meeting when i obviously didn't because i obviously didn't get my meaning across so the kinder answer is

to give them um specific and direct feedback in it almost immediately after the meeting or 10 to 15 minutes after the meeting you know give them time to decompress if

they know it didn't go well but you should go go through and be like you know the answer to the question was a bit rambly you missed the opportunity to convince people about your idea

but it is a really good idea you just need to practice your elevator pitch and notice that i gave them a specific thing that they need that they can go away and improve

and use that as like a metric for improving so i can work on my elevator pitch cool that's what it means to be honest and

kind is you're not lying to people because you want them to to to feel good you are being honest with them because there's something they can improve

but they're still doing good work and you should acknowledge that and if you were wrong if if the meaning did go well and it turns out that like oh that was just some personal bias you have come back to them later and be like

hey i figured it i figured out that you know i made a mistake there i gave you bad feedback i'm going to be honest with you and be humble

and admit that i was wrong i was wrong and i'm sorry which leads me into the third section today which is about psychological safety

which is my favorite subject oh i love psychological safety um psychological safety is probably the thing that underpins almost everything in any teams it is in

my opinion the thing that um separates successful and unsuccessful teams is having good psychological safety making people feel safe and if you're unsure what psychological

safety is it's the way i will describe it is that there is physical safety which are your physical needs like um yeah food water sleep you've also got job security

um and you've you've got like kind of like the physical needs you have four walls a roof over your head and you know you are assured that for the next x amount of months

you will have money and um a job to come to and hand in hand psychological safety is the psychological aspect of a lot of those things

so it's it's it's about the the social relationships you build it's about how safe you feel in the workplace it's about how safe you feel putting your hand up admitting that you were wrong or that or to point out

that something else is wrong how comfortable you feel challenging people in the moment instead of through back channels a good measure of like whether there is good psychological safety in

your team is to see that the next meeting that doesn't go well how many people channel feedback through their manager rather than talking to the person

directly so psychological safety is um very important and there are four different things you can do

to help build psychological safety and the number one is encourage feedback so we talked um about bringing your whole self to work

and this feeds into this section so the first thing you should do is you should be the first to ask for feedback especially negative feedback so i really like this mental model

of uh the three questions of what went well what went badly what can i do differently in the future and i think it's the same model that's sprint retrospectives use

so it's like what should i stop doing what should i start doing what should i keep doing that's essentially what that is so after a project ends or like after a meeting or a presentation or something

take some time to approach the people in the meeting and gather some feedback um talk to them directly understand you know what went well what went badly what would i do differently

in the future by seeking out criticism you make yourself more vulnerable and more open and it builds up a rapport with people and makes them more meaningful to chris to criticism from you

later it counters the whole you can dish it out but you can't take a problem and this is a the kind of theme through this is the theme i mentioned at the start of the

talk which is that it's about meeting people where they are and by encouraging feedback and being the first to do it you are

sort of inviting um untrained people to give you feedback to start with that's what builds up the trust that's what builds up the rapport

is that you are not you're not just dishing it out you're not just giving it to people unprepared when the team hasn't yet had a chance to experience or

practice with uh feedback so it's really important that you encourage feedback by doing it first by being the first person and then and then sort of like slowly rolling that out

and again i really like that model of just the three questions three questions is really easy you can do it anywhere anytime i do it all the time in things that aren't professional

um i think recently uh i we took a dog to the groomers it didn't go well so you know i talked to the groomer and i was like oh you know

how was the dog um well what what went well about the grooming what went badly and like you know what can i do differently about like bringing the dog to you because obviously there was a there was a problem here

um and you don't have to do it you don't just have to do it with problems sometimes it's really beneficial when things go really well to understand why they went well and sit

down at the end especially with projects and be like why did it go well and what should we keep doing out of that you know and also acknowledge the fact that there might have been near misses

things that like would have gone wrong in any other world but we got kind of lucky in the moment and it's really important that we understand that and build from it and

learn from it and secondly uh uh diverse teams it's just a fact um

operate better than non-diverse teams so you have to be inclusive you have to be inclusive uh to someone's background to someone's preferences um you have to be inclusive as much as

possible keep an eye out for people who maybe don't contribute as much in meetings or in documents to try to find ways to give them a voice so this is that theme of meeting them

where they are this is this is a very clear example so it might just be that you need to prompt them for feedback in a meeting or maybe you need to reevaluate totally

how you how people contribute to to meanings you should be open to different backgrounds different life experiences and talk to them learn and be honest with them and share your work self and

learn and share your personal self as well as your work self and learn about their personal self and their personal preferences offer to cater to their preferred style

of suggestions or communication you know some people like some people like documents some people like meanings um some people like anonymous voting

i remember there was one person who said that they only wanted feedback from me through over lunch that like they only ever wanted to speak over lunch if if i was going to like give them feedback good or bad about like a

presentation or a project or whatever and it it's just about listening to people and listening to how they best want to receive feedback because you don't know them you can't make any assumptions

and it's best to learn about them and like kind of be friendly and be nice and be kind and be honest about things 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 have their opinion heard

without making them feel uncomfortable give people a voice by letting them express themselves in whatever format they feel is right and then maybe bring those ideas to a central

point a meeting a document a dance off whatever works for your organization but uh often it's that it's the job of like say a manager

to cater to everyone's different experiences different life experiences and then gather all of those different points and those opinions and those views and then bring them to a central

point so that they can be discussed and maybe that might be a meaning or it might be a document but you give people a voice by listening to how they want to contribute

and then sort of trying to make a decision out of that and the third point the third pillar of psychological safety i'd say is that you shouldn't blame people um

this is different from making people accountable so um people can be accountable for the work they do but you shouldn't blame them often an individual failure is actually a failure

of either process or environment or workflows an old manager used to say to me that we put you in the position for you to make that mistake

for you to push that commit push that change and that is why the team takes ownership over it we succeed together we fail together

it it's about not attributing individual blame to people because there are environmental factors there are factors outside of that person that led to them making that mistake and

uh leading to that issue maybe we presented them with the wrong information and maybe we maybe the unit tests passed and it gave them a false sense of security um

maybe the system was in a bad state that day and i brought everything down uh you know maybe the the the person who normally supervises them

was off taking a coffee when they went when they decided to deploy it you know it's about these other external factors that ultimately culminate in an environment that allows that

um that failure to happen and we shouldn't blame them individually for that the teams and the organization as a whole should take ownership over fixing those problems and ultimately it makes people feel

safer about pulling out problems with the process or the workflow or the pipeline because they don't feel like they're having to criticize or attack an individual person they don't feel like they have to um

they they have to like identify problems with a person it's problems with a process it's problems with the environment people feel a lot safer

doing that which also kind of leads into the last point about failure try to turn failure into learning uh so it's it this is often one of those

things that is easier said than done but it's an old adage and it's important to recognize that failure is not absolute it's not the end of the world uh the business will continue on

after a failure in i would say 99.99 of the cases there are some failures which they cannot recover that's fair but um as much as possible you should understand that we fail

thousands of times a day and it's important that we learn from those failures that we dissect them that we take them to the team and that we presented to the team as like we need to learn from this and we go back to that first step of feedback and

we go okay so what well what one badly what can we do in the future uh turning failure into learning makes failure

a it means the failure isn't a an absolute in the team it means that people are okay with failing they're okay with trying and risking things

because they know they won't be punished for the failure if it doesn't go well and that's what we want in agile teams in innovative companies

we want people to take risks like not um not at greatest risks granted but we want people to take small risks every day if we took no risks no one would deploy

no features will be made and we would just be playing games that's all it is you need to turn failure into learning so we can learn from the failure and grow as a team you

often learn on like an exponential curve when you fail early and you fail often um there are situations where you can't do that

where you can't allow a lot of risk but when it does happen you should still take the opportunity to dissect it to go through it in sre we call it postmortems we go through and what

what happened we go through a timeline we go through what were the environmental factors if you have if you want to use the five wise go for it just remember there's no root cause

it's all feeding into this failure but we should learn from it and that's going to make people feel safer it's going to make people feel safer to take risks and so all of these feed into this idea

of psychological safety they're all they're all a little overlapping in a lot of different ways and you'll probably have noticed that like i mentioned certain points

um from one slide to another and are our repeated points because they're linked and they're coupled um or they're tightly coupled it's important that we build psychological safety in

our teams because that's kinder it's honestly kinder um and it's about meeting people where they are being inclusive it's about not assigning

blame individually it's about turning our failure into learning and it's about making people open to feedback both giving and receiving

which gives me which will lead me into the final fourth section of today um besides the outro is giving and receiving feedback this is

often a really tough thing for engineers because no one ever sits you down and it's like hey how do you tell someone that they caused a problem or how do you or or even how do you praise someone like how

do you praise someone how do you give someone praise in a good way that makes them feel good so specifically about negative feedback here's some general kind of like tips that i have

um start by asking for criticism um and not giving it this is that encourage feedback thing from from psychological safety you need to build up a rapport before you're before people will feel

comfortable uh trusting you with criticism and before giving you the for trusting your credibility with criticism uh you really do need to overcome that hurdle of

you can um take it as well as dish it out because that would be people's immediate first thought is that oh this person just likes to criticize everyone secondly don't make it personal it's not

about your emotions it's about theirs and i'll talk a bit more about that in the next slide but this is that idea of meeting someone where they are because it's not about how you feel in the moment

some of the feedback might be how someone made you feel but you shouldn't still be feeling that in the moment and thirdly you should be specific about praise and criticism

being really specific makes people um one trusted a lot more and again i will talk about this in the next more about this in the next slide but being specific gives people a very

specific thing to um to kind of like hang on to to latch onto to prove the credibility of what you're saying

to prove the logic of what you're saying and it also makes them in terms of praise it makes them feel a lot better because if you give general praise like if you're like oh you did great in that meeting and it's kind of

it's it's kind of nothing praise it's too general whereas if you were like oh your elevator pitch and that meeting was great it's like awesome i'm i'm so glad that my elderly approach was so good that someone decided to

highlight it and they so much about um about um understanding kindness and about what kindness is in the long run is about spontaneity about that

those like unexpected phrases that you didn't expect were happening um and it's so nice to receive them for someone to pop about an hour and be like hey i'm admiring this project and you

this is great i love this it was like oh it's so nice um and finally uh if you point out a problem try also to offer a solution if you can it's not always possible but

if you can offer a solution it gives people like a definitive jumping-off point of like okay i can approve that immediately and it gives them something to measure when they go to improve it's really important that if you have a

solution you can give it to people but you also shouldn't feel like you have to have a solution and sometimes we hold ourselves back because we don't have a solution and but it's still important to be

honest with people be inclusive with people so i mentioned i was going to talk more on this slide but there are three steps to giving feedback and there is emotion is the

number one thing take the listener's emotion into account your own like i said you should not still be in the emotion if the feedback is about your your

emotions and you should also understand where that where the where the listener is um emotionally you should understand that like if the meeting went

terribly and they know it went terribly they're gonna still feel like you know like you don't want to approach them immediately or maybe you want to comfort them for a little bit before you give them feedback

take into account where they are meet them where they are and give them the feedback that they need secondly there's credibility you need to demonstrate that you have expertise in giving this particular feedback in the

about this particular topic and you also need to show humility humility will build credibility it will it will show people that you can meet them where they are it'll show people that like

um you understand your own mistakes and that you're not perfect but credibility is about like demonstrating that like okay i have experience with this here's what you need to do

um and thirdly kind of leads into logic you should be able to show your work and uh how you reach the conclusion so people can see if there are flaws people need to be able to like go through your thought process and dissect

it and understand whether it is a valid piece of feedback that is relevant to them or if you are missing something you might be missing a piece of

uh a some an event that happened or a um or some knowledge about something that has occurred between the meetings or you know in email threads or whatever

that made someone grumpy and like a presentation and but it's important that you show your logic and you work through it so that people can [Music] can understand where you're coming from

and why you're saying it it also gives people tangible examples to work off of because you have examples through your logic and so specifically receiving um it can

be hard to receive feedback we often by not by nature are defensive people but here are some tips here are some tips and what you can do

one you can understand how you how you prefer to receive feedback and make sure people know or you correct them if you don't like receiving negative feedback um face-to-face you prefer it in writing

or you prefer lunch that's fine just make sure you let people know make sure you let people uh know ahead of time so they can prepare

in whatever way me meets you where you need to be met this is why people being kind to you is essentially what receiving is but there is a bit of yourself that you

need to be you need to be upfront about like what you prefer and how you want things to go secondly listen understand and then thank the person for their feedback

giving negative feedback is super tough you're probably gonna experience this it's super tough to tell someone that like something is going wrong that something isn't going the best um

and you should just start with thanking them for their feedback even if it's not good feedback or you don't know if it's good feedback yet just thank them because it's a tough thing to do and you want to encourage people to do it more

and practice it more and even if in the end you don't mo you find faults in their logic and don't follow through that's perfectly fine

listen understand and then thank them thirdly this is kind of related to the last point don't react in the moment take some time to gather your thoughts and processes for instance i know

personally that i'm a very defensive person when i first receive negative feedback i always need to take 10 15 minutes just to cool my head a little bit to like take a walk and process it

just to understand it a bit more why did they say it where is it coming from you know is it is the logic sound do i trust this person um am i an emotional state to properly

process this it's important that you take some time because you don't want to say something you will regret is the old adage and

fourthly uh ask for clarifications or examples where you can some people like not everyone is trained to give feedback not everyone has practice or experience giving feedback they might not include the logic of their

decisions and it's the is the most common thing that people will leave out is they will leave out the logic so you should ask for clarifications ask for examples ask for them to

run through their thought process with like why they're giving this feedback and to run you through some things you can improve and because that will give you that that's a launching point of like

okay i can i can change this i can do this differently next time it's really important oh i've been talking for a while so the next section is the last section

it's the outro and i'm going to give you some further reading so if you're interested in any of the topics we talk things that you can read more about so it's there's a wide variety of different

mediums i really love the book give and take by adam grant which i mentioned at the start it's one of my personal favorites and even if you're not in tech i generally recommend it to people and

secondly radical calendar similarly radical calendar is a great uh is great for learning about feedback and learning about honesty it's it's those two sections it's feedback and honesty that

really is what radical candor is about it's a really great book i really like the quadrant section and it's given me terms to explain it like ruin his empathy

um like challenge directly um like care personally things like that you'll have heard those phrases throughout and a lot of that the theme of that book is about meeting people where they are

about understanding what's good for them and being honest and thirdly i really like this article uh being glue from tony o'reilly it's actually a kind of transcription of a talk she did

but it's about the work between the work and that often gets forgotten doesn't get enough praise it's a really good talk and it's it's it's the glue between all of these sections so if you want to talk

if you want to look into it more it's it's a really great talk thirdly getting feedback um this is obviously the feedback section but i really like this

the article by asa mcmillan it's really insightful it's really interesting and i highly recommend it thirdly um changing company culture requires a movement not a mandate

a lot of what i talk about today is about culture changes it's about um slowly but methodically and deliberately changing the culture in your teams in your company and it's important to understand how to

do that and why to do that and this article goes into that it's really good and the last one is a little bit of a self-promotion but it if you were interested more in reading about psychological safety

particularly an introduction to psychological safety i have a good article called psychological safety and the only pyramid scheme that works and it's me but i swear it's good

promise and so finally we come to the end and in summary kindness is about good communication

it's about being honest when it helps and with your personal and work self and it's about safety it's about feeling safe where you work and

how you work and who you work with it's about feeling included it's about feeling safe to put your hand up and say that there's something wrong here

uh if you'd like to talk to me more about anything i talked about today you can we have a q a in a section where you can in a second where you can put some questions but also you can hit reach me on twitter

linkedin and that's my email as well if you want to send me an email and the last question i want to leave you today is and if it's the only thing you think

about going away from this how can you be kinder what is one thing that you can change today to be kinder in your engineering organization right now

um so thank you so much thank you thank you everyone for listening to the talk today um i was really happy to to give it and i think we're going to go into a q a now

um so if you'd like to leave your questions in the chat i can start answering them um one thing i will say is that i'm not sure if i'm supposed to

end session now because the countdown timer is still going down as if i have 40 minutes for the talk

um or not so i think i will just oh uh i got a here's a question so what are the steps to incorporate

kindness into company culture so steps to incorporate kindness into company culture one thing you can do is be very deliberate about it so for instance our company has a culture deck which is kind

of like our constitution of how we treat our culture and having a piece in there about the different things i talked about today about feedback about psychological safety and codifying them making them

deliberate things that you care about in your culture um feedback is one of the easiest ones to like write down and be like our company now believes in this um and then

sort of follow through and measure it as best as possible you will need to figure out how to measure it yourself because every company is different but feedback is one of the easiest

things you can start talking about within your company and um and starting to change because it's it's something that happens

all the time um code reviews so you can include core reviews in the feedback uh so the the the so in summary that step is to codify um

what you want to change in the culture um with regards to kindness like using some of the the topics i talked about today in particular i would recommend feedback as the first one because it's

something that helps not just engineering but everyone in general um and it's a really nice one to launch with um

some other things are so i talked about um how you should be the first to encourage feedback and stuff like that and that's about incorporating kindness into company culture

is um being the first to try something and sort of er for lacquer very term champion it in the company is a good step in um changing the

the culture yourself kind of like piece by piece you can start with um just your team and then maybe uh widen it out depending on how what your organization looks like maybe

you've got like a sub team a team and then you know the engineering organization and then the company um just work deliberately so either codify it

and champion it yourself that would be my answer i hope that answers your question it's a lot harder when it's uh when it's remote to like get feedback of like yes i have answered

your question um so a couple of years ago i was a part of a team that had put so much time into being aware of each other's sensitivities that no one

dared expressing a conflicting opinion fearing to hurt someone else's feelings do you have any sessions about what you can do to break this cycle uh yes

so this is um so actually if you read the book radical calendar that will that will go into so much detail about like that exact problem it's called ruinous empathy it's where

you have so much empathy for other people that um you grounded it and that's the example is that like if someone is drowning

the ruinous empathy um answer to that is to um stand on the shore and feel the pain of them drowning and get in the water next to them and drown yourself

and that's a problem you you shouldn't be so empathetic to the point where um you don't help so you need to have a delicate balance between caring

personally which is the empathy side and challenging directly which is the honesty you don't want to be brutally honest so you don't want all the honest