(upbeat electronic music) - All right, I'm Aman, that's Geoff.
The first thing thing going through your mind would be why are there two speakers for such a short 25 minute talk? We have only one speaker so far.
Well, one of the reasons is, we both debated that, do we both need to be here? But actually because we couldn't decide.
We are both equally passionate about this topic and we both had different lenses to apply.
So hopefully it's come through in this talk to you. But essentially what we believe in is working towards creating a work environment that looks somewhat like that.
At the end of the talk, we could do a test, though. Like, was this really about me getting an all-expenses paid trip to Melbourne? Because this is actually my first time in this wonderful city.
So it could just be that but thank you Web Directions anyway for getting me over here.
Any Indian Bollywood fans here? Cool, okay.
So one takeaway for all of you, if there's one takeaway from this, a conference, it should hard to make that Shao Kahn pose. So it goes like this, you do a side step and gradually do like this.
That's a picture I get in every city I visit for the first time.
But seriously, why are we here? We talked about scaling challenges at an organisation. So one important aspect of the culture that we want to introduce is peer feedback. Geoff and I have been working through that. We'll share some success stories that we've had with several teams and also the value they have been getting out of it and possibly leave you with some tips as to how you could go about setting something up with your teams.
So with that, we'll have Geoff.
- So, it was a couple years ago now, I joined a new team as a team lead.
And on the surface, they were actually a really great team. That picture might not really indicate that. They were churning out new features, they were doing that while maintaining a high level of quality.
And they were all actually getting along really well on a social level but I kind of noticed that just something was a little bit off and the longer that I was there, the more I noticed that there were little problems and then gradually I noticed that those little problems were quite significant. So what I was seeing is that discussions over technical solutions were devolving into argument and often, actually, people would be arguing for the same thing without even realising it. Or even if they were arguing for different things, often nobody would take a step back and realise, hey, actually we can solve both of these problems.
I think what was frustrating is that there was, I think a lot of this actually came down to the fact that people were just so passionate. So they had their idea, their customer value or the problem that they found and they just really wanted to be heard and anything that was not seen at 100% agreement with what they were saying was considered something that needed to be defended against. So this had actually just escalated and grown over time and it was just these day to day interactions were just everyone feeling really drained and frustrated and just generally shitty with each other and I wasn't really sure immediately how best to solve the problem.
- That's where I kind of come in.
If you end up talking to be on any normal day, you will see that I like to talk in terms of mantras and I go about doling out mantras at the drop of a hat and usually that'll leave you with an expression like that. That's not me, that's the person who listens to my mantra and they're like, "Should I smile? "Is this guy serious? "It looks like I should be smiling." But typically I am serious about my mantras. They're just short, easy ways for me to remind myself of the behaviours I wanna exhibit, the principles I was follow and how I wanna apply those principles into the situation at hand.
This particular one is actually taking a reflective viewpoint on what we end up focusing on on a day to day basis. Everyone here is focused on delivering something, shipping something, projects.
But what makes deliverable really successful? It's a team behind it.
If the team wasn't there, you will not be shipping anything. And what is the team composed of? It's of the individuals in the team.
Be conscious of the ratio of your focus as you go into office everyday and make sure that you emphasise enough on understanding the people you work with, what their strengths are, how do they like working with others.
And then pushing that into how your team functions. 'Cause if you have people who are strong and you've helped them in their growth, you'll have well-functioning teams and those well-functioning teams, you can trust to deliver good quality solutions to difficult problems.
I sell some of that with these value props which I believe come from peer feedback.
So essentially, you build empathy, not just you with your team members but your team members understanding each other. You remind yourself that you're responsible for individual's growth, but you share that responsibility and make it clear that your team members are responsible for each other's growth as well. It's a partnership.
And you drive self awareness.
Not just in yourself but in every team member of yours. And a bonus is that with some of the tactics, you'll enable your team to do this.
They'll actually build some soft skills which'll be relevant in other contexts as well. - So taking these two concepts that'd learnt from Aman, my theory or my hope was actually that just by introducing peer feedback to my team that that'll magically grow and build empathy and they'd be bale to resolve their issues at the team level on their own.
So we tried it and basically our developers started having these regular fortnightly one-on-ones with each other to give feedback. And now, the team feels completely different. So the devs understand each other a lot better, the personal growth and empathy that they've seen has allowed them to trust in each other's decisions. They just understand now where different perspectives are coming from.
There was one developer that said to me that he now understood what one of the others was placing value in to the point where he actually understood where the technical stances were coming from. And this didn't necessarily mean that either of them were right or wrong, in fact actually, usually everyone was right. But it gave them a place to have more of a conversation. So my team was now a lot of effective at communicating their real, genuine concerns and they were using a lot more of a common language, they were asking the right questions to understand each other, and meetings and technical discussions were just now generally so much more enjoyable for everybody.
And just remember as well that this was all done by giving individuals the tools and the space to grow. So by focusing on individuals by introducing peer feedback for the team, our theory was actually kind of spot on, they were able to fix some of the problems on their own. - So where does that leave the team? Are we done when you actually have a well-functioning team? Or do you actually believe that the team can continue to improve? That's where this ties in with the growth mindset. That there is no stopping to improvement.
What does that really mean in terms of feedback? I personally have benefited from working in a place where feedback culture was very evident day to day.
Especially peer feedback.
So in my journey through ThoughtWorks, I had accelerated growth.
Majority of which, I'll actually credit to the feedback I received from my peers.
It didn't always have to be my manager or the client, but actually people I was working with day to day. And what's important to call out about that feedback is that the focus has always been on continuous improvement and growth which means then does feedback actually have to be good or bad? Does it actually have to be positive or negative? That is not feedback.
- So, if that's not feedback then what are we actually talking about when we say feedback? It's not an assessment.
So performance assessment is an aggregation at a point in time, you wanna be drawing on as many sources as you can to try to be as objective as you can.
One-on-one feedback, on the other hand, is not objective. It's allowed to be, in fact it's supposed to be subjective. It's about your own personal experience of a situation. So your perception of that, the impact that that had one you is kind of what makes feedback actually always about the two of you, the two people. Compliments are not feedback either.
So while we all like to hear things like, "You're a great developer," or maybe in this room, "You're a great leader," that's not feedback either.
So this is what we're talking about when we mean feedback. It needs to be actionable and needs to be relatable. Using these models to structure feedback, it can help developers be a lot more comfortable about giving it and also a lot more effective at making it actionable and relatable.
So rather than thinking of positives versus negatives, we're talking about strengthening confidence and setting people up for growth.
Onions, like people, like parfait, have layers. So, basically you can't know a person's core values or beliefs so when you're giving feedback, you wanna stick to those outer layers.
You wanna stick to their observable behaviour. And something that was touched on before is you wanna help people understand the real impact that they're having.
So a really good model for this is something called SBI or situation-behavior-impact. Basically, it's focusing on trying to be as objective and clear as possible when you're talking about someone's actions or behaviour and it allows you to be subjective about how that impacted you.
So these are models that we use Atlassian and I would, probably most, personally I would put that down to Aman introducing them. - So what's the backstory here? In late 2015, I joined Atlassian and what a second nature to me as part of the observed culture of the organisation that I saw in the company I spent most of my career with, I wanted to see how I could replicate some of that in Atlassian itself.
So I started small with my own team that I was leading and introduced some of the peer feedback concepts. And I saw good, positive outcomes of that.
It gained interest and I wrote a blog post, and internal blog post about it which got very, very popular.
Possibly because I timed it along with the annual appraisal so it actually got the attention.
And then there were a lot of requests from other teams in Atlassian as to how do you go about doing this.
And I again started simple.
I actually focused a lot on enabling team members to get started on that journey. I'll talk a little bit about that.
And later, Geoff will talk about how you can carry that through with your teams. So in particular for enabling your team, what I did was I made sure that I collected the material for the models that people need to understand. How to shift their mindset.
And some of the structures that we talked about like the SBI model, I documented.
So it included the how but also the why and also some examples that they could relate to. I supplemented that with a workshop that I designed and I started running for teams on request. Very important was that I made sure that it was not a dry, like an HR-driven feedback session which has awkward role play between participants. I kind of make it a bit impersonal by using art pieces that could give feedback about, pretending that you are giving feedback to the artist. Or there's a comic strip sit-com that's happening and you're role playing as if you're part of that situation. And it got received very well.
I made it remote-friendly as well, 'cause we have a trello team and they were one of the people who requested. So it can actually work well in a diverse set of set-ups which can give the large companies and the various type of teams you may have in your organisation.
And finally, you leave that workshop with a very clear action item for the team to continue on this journey.
A very simple one is to schedule a regular feedback session for that team and that involves just 30 minutes maybe fortnightly, that's how you start.
Within that session, you actually have people paired up, so team members paired up as to who will give feedback to whom.
You wanna make it simple and one-directional so that doesn't become a two-way conversation or a dialogue. Feedback is typically what you want to covey as a feedback giver to the feedback receiver so you set it up like that.
And you make sure that the team members focus on structure and practising regularly because this'll be difficult and it'll take time. And your content can mature gradually.
You don't have to hit the hard topics on day one. And just to make sure that there is readiness, preparedness of the team, you can actually use a tool like this.
This is a conference page with a simple table which has a schedule and tracks who has given feedback to whom on what date. Of course, I've been privacy conscious, I've removed the names there, but the columns and the rows are names of your team members. - So as your team goes beyond that workshop, the introduction part of it, you wanna give them a few tips and you wanna check in with them from time to time. I think the first thing you wanna focus on which Aman eluded to a little bit is actually just the structure of people's feedback. So basically with a fortnightly calendar invite, your devs are probably not gonna remember that that is coming up and it will come around and then they will just try and wing it.
So while thinking up that sort of thing on the spot is really great, it's hard.
And actually, giving feedback is hard in itself so you wanna kind of encourage them to put a little bit of prep time in.
So maybe write down during the week, in the SBI format, write down some of the feedback. This will allow them to think more deeply about it. And it also let's the conversations focus more on the content rather than struggling through trying to phrase it correctly. So you should also get them to reflect on their process a little bit.
So in your one-on-ones, ask them things like, just check in with them, are they sticking to the structure? What feedback are they soliciting? What are they learning through their feedback? And also, I would suggest to ask them to spend like five minutes at the end of their feedback sessions to have a bit of a meta-reflection between the two people about how it just went. The next thing you're gonna want to focus on is actually the content.
So, a dev told me once that he didn't have any feedback to give.
That he already gave all of his feedback in Code Review. And there's just so much more to working with people than just directly through code.
I kind of asked him, like, "Well, what about in meetings? "What about how someone responded during an incident?" As leaders, it's our job to pay attention to how people work and I think what we're suggesting is that devs should be doing this as well.
And while the might think that they are doing that already, they're going to have to really start taking notice of their peers in more dimensions than just code.
So, something that we did to help people get an indication of what to talk about, we actually created a focus areas page where everyone listed out all of the areas for growth that they were interested in getting feedback on. So this just helped people get an idea of what to watch out for.
So, something else I've also noticed, in my experience, feedback tends to become very negative focused and I realised that we've been saying that there is no negative or positive but that's what devs can slide back into if you don't help them keep on track.
So what I saw was the feedback sessions focused more on what people thought was bad behaviour that needed correcting rather than thinking of it as continuous growth. So when I noticed this happening, really just through the one-on-ones and stuff, I just raised it in one of our regular retrospectives and the team decided to add a little thing to our focus areas page but I really think that it was just raising it and talking about it as a team that allowed them to course correct on their own. So this was our focus areas page.
Similarly to Aman's, just greyed out the personally identifiable information.
It's really just a dot point list of things to watch out for.
And what I though was really cool about this was just the fact that people were comfortable sharing this with each other.
So this is just locked down to our team but still, I thought it was impressive.
So, you've introduced it to your team and they've been doing the feedback sessions for a while now and you wanna let them perfect their process. So you wanna get them aligned on the value of the process. So ask them what they think the value is that they wanna get out of it and ask if they think that they're getting that value. So I did this with my team in a dedicated retrospective about six months into the process and just set them up with some example, like seeded some questions like, are our sessions at the right cadence? Are people getting actionable feedback in the areas? Are people sticking to the structure? You kinda wanna keep drilling that into them. So a possibly more advanced question you can ask if you want is are their one-on-ones awkward enough? I don't know if people have read this really great article by some called Mark Rabkin. Basically, he talks about how in one-on-ones, pushing the conversation into the more difficult areas is going to give you the most growth, both personally and interpersonally.
So encourage your team to continue this improvement process just in their regular retros but I think having that single dedicated one was pretty important.
And also keep in mind that every team's unique. So they're going to change the process, not only just depending on themselves but also on what value they've agreed that they wanna be trying to get out of the process. And that's okay.
I think it almost doesn't matter where you end up with this. If they align on a value, then you can help them iterate on the process to get more of that value.
Yeah, so thinking about what's next for my team. When I introduced it to my team, I had short-term goals in mind and I feel like we actually achieved them quite quickly, really.
Within three months I was seeing significant improvements. But I feel like our next goal is to transition from this process that we've got to truer feedback culture like Aman has seen at ThoughtWorks.
I think it'll be interesting to see how, or if it's even possible for us to get, for our team to take that leap to that culture. The challenge that I'm seeing at the moment is actually that people run out of feedback to give and that's a very contentious point there.
Aman and I have argued.
I've argued with other people.
I think it's they haven't really run out, it's a little bit more nuanced than that, but basically we're struggling to maintain momentum with the process over time.
If anyone has any ideas, I'd love to hear them. But, to be honest, I think even if we never get there, just through the process alone, we've really gained a lot. We've all grown a lot as individuals and as a team. - So quick recap.
You saw these value earlier.
But I think as leaders in this room, remember that you get a lot of value out of introducing such peer feedback culture as well. It's very important as a leader that you start to build empathy and you lead by example and help your team members build empathy for each other. As a manager, of course it's part of your job description that you grow the individuals in your team. And again, as a leader, one of the top qualities cited is usually self awareness.
So that's something you'll gain over time.
These are the mantras that we've already seen. So hopefully you'll have some recall value for them. I'll introduce a bonus mantra for you, feedback is a gift, and that analogy stretches well, really.
If you reflect back on the last time you received a gift that you really like, or reflect back on last time you actually gave a special gift to someone, you probably remember that was thoughtful gift, the item that you chose was very thoughtful, very appropriate for the person that you intended it for. So that's the feedback content itself, what topics you wanna broach with the person. You probably gift wrapped that item with love and care so that's kind of the structure you apply on the content. And then finally, no strings attached.
If you give a gift to a person, let's say a dress, you don't expect them to wear it immediately the next day or even the next month, right? You leave it up to the person to use the gift as and when they see appropriate. So that's kind of important.
So feedback is not an expectation-setting conversation. You can use similar structures to have an expectation-setting conversation but you should be very explicit about that. And finally, I leave you with this thought, be opinionated.
If you're convinced about the value here, pick one that you are really aiming for, make that transparent to the team and see how you can get that going in your team. So for Geoff it was that feedback conversations should be verbal, so that actually helps you build multiple skills including your communication skills.
For me, the aspect of feedback I'm very passionate about is that it should not be anonymous.
And I work really hard to build that culture of trust and partnership where you do not need anonymous feedback.
And you could choose anything else.
Maybe that you don't need a scheduled feedback sharing time, it should be ad hoc, timely, when required. It'll be hard, it'll be difficult but you have to start somewhere.
Thanks.
(applause) (upbeat music)
