Hello, everyone. As I've been nicely introduced, my name is Ben, and I'm here to talk to you about the process of giving and receiving feedback. So this will be focused more on informal feedback, on your work, ideas, rather than a formal feedback that you might do as part of a performance review.
There are many great sessions specifically around performance reviews, and so I didn't want to go over exactly the same ground. So, this is me. My name is Ben. I'm a "solution architect" at KPMG. I work preliminarily in the Microsoft Dynamics Space, if anyone has played around that, but moonlighted as a customs DevOps dev. I live in a small village outside Northamptonshire in the UK, and I currently balance working at home with my wife, my two small children, and my cat. I didn't have a picture of the cat, I'm afraid. So, what about you? So I appreciate we've got quite a varied audience here, so let's introduce our play of characters. Perhaps you're our first character: a more junior developer. Maybe you're fresh out of school or university, or you're an apprentice, and you're taking the first step of your journey into working in tech.
This session's designed to kind of give you the ability to maximise the effectiveness of the feedback that you've received. Maybe you're the next step on - maybe you're a more senior engineer, and you're acting as a lead on a project, or a programme, and you're a mentor on a number of different junior engineers fresh in the business. The idea here is we will aim to nurture that - help you to nurture that creative spark that comes with new talent, whilst also maintaining the relationship into management as well.
Finally, we have people in the management capability, who maybe are further away from the coal face day-to-day, but want to maintain that good relationship with their technical staff and produce effective feedback and ensure that the best ideas get brought forward. So hopefully, there's something in this talk for everyone. Some people may sit between a couple of these roles - I know I probably do personally - but lets start with a scenario that hopefully we're all familiar with.
So, as people often talk about, making software, it's a creative endeavour. It's fraught with analysis, confusion, frustration, and, yes, probably sometimes even tears. But it's all worth it in the white-hot thrill of the chase for that magical moment where you stand up from behind your desk, knock your coffee over and shout, "It only works!" But even when we've made what we believe is the most innovative amazing application that the world has ever seen, it can sometimes really only be the start of the process, to make it from something that was a sketch, or a PowerPoint, or a proof of concept, to something that can be rolled out to customers or a production system, it can be a daunting process, especially if you're new to the industry or your employer. We've got to battle things like corporate policies, battle-hardened egos and process and is habits that have been formed over years years - over years and years.
It can lead you to think, "I don't know where to start? How do I maximise the feedback on my idea or piece of work?" What we are going to do today is talk through three mainly important ideas about how you and your colleagues can maximise the effectiveness of the feedback that you give and receive. The three things I like to focus on are, number one, purpose. It's really important that we understand that, when we are asking for feedback, we know exactly what its purpose is, so that we can give and receive the feedback that everyone is looking for. Number two is the audience. When we are demonstrating our ideas, or our work, we need to be sure that the correct people are seeing it, so it's correctly understood. And finally, this concept of fidelity, so, when we are making a pitch of our great new idea, we need to make sure it's at the right stage with the right level of detail so we maximise the effective feedback that we get.
First of all, let's talk about purpose. There was a great talk in Birmingham which recommended a fantastic book called Thanks for the Feedback. We are using the definitions in that book. The first type of feedback is appreciation. Now, we all want to feel wanted. We don't want to be taken for granted. We work hard, and, if we're not recognised, that kind of feels bad, so a great way to boil the appreciation down is to think of down to its essence is to think of how we might give feedback to a small child. So a child might come running up to you, "Daddy, mummy said I could do 100 jumps in one minute and I did!" All you can say is, "Wow, amazing." This actually happened, so this is a representation of me and my daughter. Small children love all kinds of feedback, but particularly crave appreciation especially from parents. That gives a good hit of oxytocin and makes everyone feel happy. Is appreciation just for children? Of course not. I think we wouldn't be breeding a good working culture if we didn't appreciate what we did. Here is some broad advice about how we manage appreciative feedback.
The first thing is, appreciative feedback needs to be specific and authentic. If everyone gets massive high-fives, compensation, and great feedback just for coming to work every day, it kind of loses its value. It needs to be on something very, very specific, and that gives it its authenticity.
It also needs to be given in a more timely manner, so you would be amazed how quickly people forget how appreciative they've been of someone. You may appreciate something they did one day but by the next week, you've forgot, and that person is another resource to you. Make sure we give it in a timely fashion. One of the things is, appreciate feedback is not something that we necessarily explicitly ask for, it's something we come to expect by going over and above, or doing the extra hours, or solving a particular challenge, but we have to recognise that maybe due to time constraints, or people crunching on projects, it may not be as free-flowing when we would like. It's great when we get it, but we need to be honest with ourselves and recognise it's not as free-flowing as we would like.
If you get some appreciative feedback for someone you works for you or with you, make sure that it gets surfaced in the right places and seen to the people who matter. I'm a line manager for four different people in my company, and one of the things that I'm on like a laser beam is any time I get appreciative feedback from any member of my staff, whether it an email, a WhatsApp message, a message on Teams, I make sure it gets logged in our performance-management system because what will happen is, if you leave that to the end of the performance year, it will - everyone will be too pressured doing their performance reviews and no-one will remember.
Do it timely, and do it straightaway. One of the other things we need to recognise is that appreciative feedback has a big non-verbal part of it. All feedback has some element of a non-verbal component, but appreciative feedback is probably the most. So it's very easy to appreciate someone through gritted teeth, but you need to watch how you manage non-verbal communication when it comes to appreciative feedback. The next stage is evaluation.
Evaluation is the biggest and scariest type of feedback. It's one we've become accustomed to since school. We all carry an example of evaluative feedbacks on CVs. My art teacher evaluating my performance and thought I was worth an F. An F is what I was worth. I didn't draw these sprites, just so you know! Evaluation can be kind of quantitative, and sometimes a little bit cold compared to other types of feedback, and it often has to be quite objective.
There are two main types of evaluative feedback that we are probably used to working day-to-day. One is our end-of-year performance review we're all familiar with, and the second is our old friend: the code review. We look forward to these as much as we look forward to a trip to the dentist. I'm sure we could fill several volumes of just code review memes. Why do I have to defend my great work? You may find the machines don't understand what you doing. Warnings, build errors, PRs rejected, and it takes you two months to get anything merged on to master because of all of this damned bureaucracy! We need to relax. One of the reasons we can get evaluative feedback from the machine is that it is inherently objective. We need to try and sit back and take some of the emotion out of it. Notice I didn't say take all of the emotion out of it, because I think that's pretty much impossible.
When you're giving evaluative feedback to another member of staff, one of the big things to this about is this concept of candour. So candour is an old word, comes from Latin, and it means brightness, whiteness, and also means to shine, or I shine, but in around 1600, it adopted a new meaning, and that is the state of being sincere, open in speech, and honesty in expression. Anyone who has read Creativity Inc knows that candour is at the heart of the Pixar dream, Braintrust process, and it is how they evolve the concept of film ideas and how they produce such great output. Candour is something they bring to the table every single time.
We need to be candid in our feedback when it is evaluative, not brutal. We need to point at everything that is there, bring everything out into the light, but we need to do it with an empathy to the people we are speaking to. As any creator, - every software engineer is a creator - we are proud of what we do. We don't want people pulling it apart, it doesn't seem fair. It's very, very hard to argue with someone who is being complete, open, and candid. Emotions: use them well. If you believe something is wrong, do say it. Be candid in your disagreements, but be respectful.
People sometimes don't bring enough emotion into certain types of feedback, and it results in things getting lost in translation. If you say I'm not sure that's the most optimal process, the person receiving the feedback may think great, it's not the most optimal, but I will carry on with it regardless. If you vehemently disagree and say I think that is suboptimal, we should not use it, that brings the point across more clearly. The way to bring it together is looking at alternative viewpoint. If you spot something in a piece of work, or an idea someone has presented to you that you don't agree with, or you think is a bad way to go, don't say something so simple as "it's bad", but let's point to the thing exists, and allow your receiver feedback to take that next step themselves and come up with why something may be bad, or it may be worth a further look. Credit to Lindsey Ellis who is a great YouTuber for this quote. I stole this totally from her.
The final purpose of feedback is this idea of coaching. So, evaluation and coaching often come hand in hand, and many people would argue that a piece of evaluative feedback is much, much more powerful with some coaching attached. It's all part of the Agile cycle of learning, doing, and adjusting.
Coaching is basically how we learn. We try, we do, and we try, we get some coaching, and we adjust. And just like Agile, coaching should be primarily focused on how to be better. Without a strict focus of what is wrong or right. Evaluative kind of handles that for us. Coaching should take you down paths that perhaps may be you've never really considered before. One of the best ways of looking at this when it comes to coaching is something that comes up quite a lot. It is how to solve a problem.
Now, we may coach people on how to solve problems, but the problem with problems, for lack of a better expression, is sometimes they're quite nuanced, and without all the detail that may be needed to fully understand, and you may find that, if you offer someone some coaching on a particular problem, because of the lack of context, you may be a bit misled or guide someone down an avenue that isn't quite correct.
So, when you're asking someone to give you some coaching, try and focus on a particular problem, and try and present it in a way that is understandable and easy to digest. Give your coach the correct perspective. For example, a maze is much easier to analyse looking top down than looking at from the side. One of the things to remember when we are talking about solving a problem is there are, in fact, multiple routes we might take.
There are the dead ends, things that are the wrong ways to go about things. They're almost almost universally agreed. These are classic things like security vulnerability, or a single point of failure, or not using the dark theme on your IDE - it's just not allowed. Beyond that, there is the road less travelled. Your junior may have done something differently to how you've done it in the past. Try and be open-minded and try to talk the path they talked to get an understanding of how they got to the result they had. You may find there's an avenue that previously hadn't been undertaken that's worth investigating, even if it isn't the direct solution to this problem, you may discover interesting new features that you can use elsewhere.
Technologies change and evolve, so a fresh pair of eyes can often provide new insight and not necessarily blinkered by the way this is the way it's always been done. But there is the enterprise highway, so there are sometimes more efficient ways of doing things. All these policies and regulations that need to be adhered to, and we need to be open-minded when we receive feedback from people who are more experienced on this. Sometimes, you may find the problem is when you present your solution, the problem has previously been solved a different way, and we have to be aware that in organisations, that this sort of stuff may happen. But it's always, again, it's always important to remember to question the status quo. Remember, you weren't hired just to say yes. We have this thing called "apparent credibility" which sometimes can hide a lack of understanding.
You may get some feedback to go down a particular route from someone who just seemed so credible that you wouldn't dream of questioning that what their advice they've given you is correct. Often, it can hide something they don't quite understand. I've got a great story about how apparently the credibility has led me down the wrong path from an early point in my career. I don't have time to go through it right now, but you can ask me in the chat if you want me to go through it as an example. One thing you may be faced with is: that's not how we do things in the enterprise. As an architect, I hate this. I'm sick to death of this. Yes, I know when you scale something is to the to the enterprise, it has different constraints, regulations, and it has to adhere to standards that maybe you've never heard before, but I don't generally accept this is a blind piece of coaching. Imagine the enterprise changes.
Imagine if we got - if you had this statement said to an idea about working remotely back in November last year. It would have been a perfect acceptable thing to hide behind but it wouldn't have worked. The situation we're in now is a great example of how the way we've done things in the past need to change, depending on a number of external factors, so don't necessarily just accept that is the way we do things, because if they can tell you why, that's fine, but, if they can't, maybe there's another avenue to pursue there.
If we did everything the enterprise way, we would end up with things like this. Anyone who has ever done a technical interview may have done something with FizzBuzz, where you count up from one, and you have to replace certain multiples of certain numbers with the words "fizz" or "buzz". If you go over some of the details, there are great ones like integer, integer, string, return a factory, which I think is absolute genius, so the enterprise is good, but we need always to be open-minded in the ways that we look at problems.
Where this can go wrong is where we get purpose mismatches. So, when you're looking for one particular type of feedback, but you inadvertently receive another type in return. For example, if you burn the midnight oil and merge the particular complicated PR on to the master branch to push it into production, and you send an email to your boss, what you probably don't want first thing in the morning is some cold evaluative feedback about what exactly is wrong with it. What you probably want is some appreciate feedback to say, "Great, thanks for that, good job." It can then put you in a pretty bad mood. For example, your junior may not be happy with a, "Thanks for this" when they need help get getting to the next level.
Be clear in asking for feedback what the purpose is. If you need coaching, use a phrase like, "Can you provide guidance on this?" Rather than, "Does this work?" When giving feedback, loop back at the end and ask if that is what they were looking for, to give a chance for the person looking at the feedback to clarify or re- clarify. Yes, feedback on feedback is a very real thing. So the next thing I want to talk about is the audience. We've identified the three types of feedback we're going to proceed poop who are you targeting it to? Doing a live demo to the catering team is not really going to get you the result you want. The advice here is to get it across multiple groups of people.
I think a lot of people go to their manager in the first Sri Lankans just because that's the most obvious route, but if you spread the idea to a number of different groups, you get a lot of different perspectives, especially because certain groups, not mentioning names, tend to be of a particular demographic, and having a wide range of viewpoints will give you a better viewpoint where your idea may go, and it might stop people taking credit for your idea if more and more people know about it. Remember, the audience have different drivers.
Your peers may be playing in the sandbox with you day in, day out, your mentors or your leads are more interested in what your idea can do, and your managers more interested in the whys - why is this so valuable? Finally, this concept of fidelity. The fidelity of your idea will mostly depend on what you're trying to present and the audience you're requesting feedback from. Whether did is a detailed engineering drawing or whether I write something out in crayons.
If you're presenting concept for a new encryption cipher to your information security team, you probably need a hire level of fidelity than presenting a new concept of a picture gallery to your social immediate by a team. It's all about getting the right detail at the right time, so, in my experience, don't try and show code snippets to senior management. Really, sometimes, they can only think in PowerPoint. So, we're here, we've got our great idea, we've got some great feedback from our peers and mentors, we've pitched the fidelity just right, everyone is standing behind me, I've got everything I need, and ready to go.
One little aside before we finish. That's what I like to call the death and taxes caveat. Sometimes, despite your idea being well formed, having great fidelity and the will of the people behind it, everyone thinking it's absolutely great, there is a partner or a senior stakeholder, a customer, or a person higher up in your own organisation who just says no. And this happens, just like death and taxes. And sometimes you've just got to roll with it.
My advice in a situation is consider whether this is a battle you think is worth investing your time in? Sometimes, even if the client or the manager is being completely ill ological and irrational - illogical, it's not worth your effort. Think of it rather as "not now" and think of it getting time back to go out and be more awesome. Get some written evidence you tried to lead them down the correct path, get a cup of tea, and get on with your day. There is one caveat to the caveat: if the answer to no is condoning illegal or immoral behaviour, that fight is worth taking and going further up if necessary. I work for a regulated company and it's something we are taught a lot. That is a pretty downbeat way to end this talk.
I don't want to do that. I want to finish on three key messages to try to emphasise the point of accepting it but trying to get the best out of it. The first one is you weren't hired just to say yes. You were hired for your insight and your input, your creative thinking, and your ability to kind of bring the company forward. If we all just agreed with what the status quo was, we wouldn't advance, innovate, and we wouldn't get the result we want.
The second one is creativity is not just for the experienced. So people think that you need years and years of experience to come up with a great idea, and it's not worth going for feedback until you have had that grounding in reality, and that's just not true. Great ideas come from people who are not experienced all the time. You just need a blank slate, and a complete lack of a predetermined way of going.
Finally, you have taste, you have ideas, you have drive, you have things you believe in. Don't be afraid to use it. Thank you very much, and I welcome your feedback.