Welcome to the Managing Engineers Podcast with Adrian Lansdown and Cy Jobbling. Today we're talking about team health. Hello, Cy.

Hello, Adrian. How are you?

I'm right. How are you today?

I'm doing pretty well. I've had my walk, I've had my food. I'm in a better place, in a.

Better place to talk about team health.

I'm feeling healthy. Get it?

See what I did there? Dreadful.

Let's get to the content as quick you uncomfortable underneath. That's the way I do it.

Awkward.

How are you doing before we get into the topic?

I'm all right. Healthy enough. I've been for a walk, been outside today, which makes a change. And it's sunny. It's not so hot. So good.

Excellent. The air's cooled down a little bit from last time. Just a little manageable.

It's not raining at the moment, which is perk.

It's a very British observation. Is it raining? How hot is it? Let's talk about those topics for five minutes before we do anything important.

I'd love to start a weather podcast.

But way too on point and out of date quickly.

Are you ready to get into the content now that we're finished the weather updates?

Let's move on quickly.

Okay, so what's the importance? Team health? Why do we do it? What's the point?

Team health? Yeah. It's an interesting topic that's come up for me this year or so. For those that don't know, I have been working on a framework called Petals, which kind of helps teams be more self aware of their general health and ideally improving things. But I just wanted to bring it into this conversation and work out, is there any importance in this? Why do we do it? What is a healthy team in your thoughts? I've picked five main areas to focus on, but we're not limited in that sense. The model works with most, but I'm just curious what your thoughts are generally on, like, healthy teams, unhealthy teams?

Yeah. I think it comes back to if you've got a good, healthy team, they're going to be more productive and kicking out more code, which is always the important thing. The high quality code. I think the things you're looking at is sort of the morale of the team, making sure that's high, they're happy content in themselves, they're open to communication with each other, sort of working around with those, which hopefully in turn gives them a nice consistent velocity of kicking out work. And then if they're working together, when these conflicts do come up, when these issues do come up in production, they're all going to join together and really impact that to make a change together as one instead of silos of people, which we often fight across.

Yes. I mean, you've called out three key areas there around productivity, getting things done, teamwork working together, and they're the main ones. I think I'm focused there. But there are the other parts that are less tangible, I guess less valuable in some eyes, not saying in all, but why care if your team are enjoying what they're doing? Does everyone come to work to enjoy what they're doing?

Wow.

Some just quite happy to go now. Just give me the code to do them out. Bye. And I don't have that purpose in life to really enjoy what I do.

Yeah. And I think as we look at larger scale teams or larger production scales, when you've got several thousand hits per second that you're talking into, you can't rely on just that one person. So it's also about building up that team and not having the rock star developer that's really going to like, doing all the stories, kicking it all out, that's great. But if they're not working well as a team, they're going to quickly burn out on the other side of things you do. They have those people, they come nine to five. They just want to kick the story and then finish. But I'd also say this helps them lean in to know how the rest of the team are doing. If one person is all good and happy, but the rest of the team's a bit sad. That's why you need to look at the team's sort of overall health, how they are to bring them into it, hopefully are. And if they're not, if they are the rock star developer, it's like, how much are they really bringing to the team? True.

I mean, the key word here is team. What makes a good team? What makes a healthy team in a way. But why have a team at all when you could just have a load of individuals working in their own way? I don't see the value in that personally, but I think I've seen it in the past where I've worked in an organization. You have one person to one project and that's it. Is it working? Sure. Are they getting true value? I don't know. Is there opportunities to share knowledge, share and help each other? Probably?

No. I think if you rely on that one person, you're just creating so many bigger issues. I think definitely we can see the indie developer that's creating their iPhone app. That's great. There's that one person it relies on. That's all it really needs. That works well. I think when you start to get into these team situations, especially when you get into these larger teams or the larger business that has reliance upon multiple teams, can't just count on one person and that one person should have a team to support them and they should support the team.

Yes. Agreed. This is where it all comes from for me, is just I'm seeing some of the challenges, the complications, the difficulties in teams, even, like the communication between team members and unhealthy dynamics that you like, how can I nip this in the bud? As a manager, this is something that I want the team to be more aware of. But specifically those individuals. If that's the situation, but try and catch it earlier and maybe this is where Belly and Pelts comes in. Seeing some numbers to kind of quantify where the teams feel things are at.

It is a very unquantifiable area really. You can look at a number of metrics and teams start to cheat them. They don't always rely, they can just focus on what's going into production, how many stories are getting kicked out. They don't necessarily rely on is this team a happy team, which you've said maybe is not a key thing to you in your company, but I think overall is very important for keeping people, keeping low turnover rates. If they're not happy, they'll go to somewhere else. It's more fun.

Well, this is my point as well. It depends on the culture of the organization. We're quite lucky that we work in an organization that values the people that they have and tries to make sure that they feel empowered to do the right thing and fundamentally keep them happy. We don't them disappearing like quick churn, all that sort of stuff. So if we've got a healthy team that enjoy what they're doing, see the value in what they're doing, learning, working together and all that good stuff, and stress sort of not boring, but at least managed well, you've got a team that could effectively be there for a long time and continue to deliver value.

And I think it's that understanding of there are going to be times when there's higher stress, there's times when there's lower stress. It's just having an understanding that that's there how people are feeling. There could be something outside when you've got people working across multiple teams, could be that that person actually is feeling more stressed because they've got something else going on and how can the rest of the team help them?

So I'll do a very quick overview on what Petals is for those have not followed along that journey.

All right, let's jump into Petals.

This is the good stuff briefly, just because it gives you a bit more context. It's basically a five dimension visualization of five key factors. So you got productivity, which is the P enjoyment, which is the E teamwork, which is the T learning, which is the L, and Serenity, which is the S. Altogether it comes up with petals without an A. But the A is the average that you get from all five scores. Every individual goes in scores, their iteration out of five. You get personal scores, you get then shared averages across the team and then you can start to look at the outliers compared to averages and all that sort of good stuff. It gives you some subjective numbers anyway as a team to kind of then have a conversation and go, right, how is it looking? Have we got any ones that we need to address? Have we got any fives that we need to recognize have we got any individuals that are very low compared to others that are not? But that's the framework in a nutshell, and we've had some mixed results, I think, from introducing it to a lot of our teams.

Yeah, and I think it's helpful to have that because it does bring into this piece of not everything is quantifiable. Everything comes down to starting a conversation. And I think at the team level, sometimes it's hard to do that. Sometimes it's hard for someone to stand up in a group of eight people and say, oh, yeah, I'm feeling really stressed at the moment, which I can understand, versus if everyone's completing an anonymous score, being able to put that in and saying, yeah, I'm stressed. And then maybe it's like if you've got multiple people or maybe you got one person that makes the rest of the team aware and maybe they can help out with that without knowing the specific person. If they don't want to call themselves out or if it's across the board, it's like, right, four out of five people on this team are stressed. What can we do in this area? Can we talk about it? What can we do to relieve that stress?

Yeah, agreed. And so what I've seen many teams do is introduce this to their retrospectives every two weeks. They use petals as a starting point, not as an icebreaker, but as a starting point to get some ideas of how people the team are feeling. Ideally, they take into their retrospectives and reference it. While we're on the topic of the X, our learning score is quite low, this sprint. What are we going to do about that? That's what we try to do, and as managers as well, we can cross reference the two topics if it comes up. You made an interesting point there about the metrics, and I think we've talked about this in another conversation around monitoring productivity and contributions, which is, again, very dangerous territory to go down, but you can still correlate the data to productivity. The team feel like they've had a really strong sprint, but if they look at the metrics, nothing's gone live. What's happened? Why do you feel like you've been productive, then? Well, you didn't spend us mobbing for four days on this one problem, which was amazing to do as a team. Got a load of stuff done eventually, just not been shipped yet. It's nearly there, but it just gives you extra context with a subjective score from across the team.

As an engineering manager, how can you sort of monitor and observe the team?

There's multiple ways of doing this for me. The obvious one is just looking at that data snapshot on a timeline axis. Right. You've got some anonymized scores, ideally, but ideally it should be personalized. You can identify who said what, but if the team aren't safe enough to do that, make it anonymous. There's no requirement to do that. But part of the conversation should sort of surface scores anyway, so you're kind of going, oh, no, that they were low that time anyway. As a manager, I'd like to keep an eye on the team overall numbers over time and then optionally monitor individuals. Because if I see a running fee with a certain individual, that's relatively low. I'd like to capture that now, because they might not bring it up in a conversation. They might not sort of say anything directly to me. In a one to one or through some messages or anything like that, but I can equally go in and say, right, just my personal observation is I've seen that you've been low scores on your pet rules over the last month or so. Should we talk about that a bit more? And is there anything you want to deep dive into and ideally find some solutions for you? I think an engineering manager could use that data, but don't just assume that you know what the answers are. You need to, as you said, have that conversation with people either as a collective or as an individual.

Yeah, I think it comes into it's another one of those conversation starters. That's what it's really here for, just to be able to sort of start that conversation and maybe the person opens up and goes, yeah, I was the one, I'm really stressed, or maybe they don't want to open up and maybe it's not them. And then you can have a conversation about what they could do to help the team reach out across the team and sort of enabling them to be able to be more self aware of how the team might be feeling or the health of the team at that point.

Indeed. And the other angle to this is you can see the people that are constantly scoring highly or in a certain area, they always got a high score. So you play on that strength as well as the improvement area, you sort of go, this person's always learning something. Why is that one not learning anything? Maybe if I find out what they're doing and even it's just like micro learning stuff going, Every day is a school day. Love your attitude.

Thank you very much.

Whereas when people are going, oh, I've never gotten training or conferences, I'm like, well, that's limited in capacity or budgets for whatever reasons we've got that. You just don't get the time to do that. Don't think of it as, you have to have a big bang learning opportunity, just see what you can chip away at instead. But I just think, yeah, the numbers mean very little on their own. They are, as you say, conversation starters again.

Yeah, which is what it all comes down to.

So going back to that point, like a healthy tea, was there anything I've missed in those sort of five areas that you think would be more useful?

I don't think so. I think it gives a I'm biased because I've used it. So I think it gives you an area to concentrate across those areas, and I think it keeps you away from sort of treating it as a productivity tool. True. Obviously it has impact to fill into that. But I think if you start to look at like, right, if we were to record how many stories we've completed this week or sort of going through there, there's obviously bits around if the team's got goals or sprint goals, maybe there's something about in a standard sprint that's a pass fail. But how does a team feel about that? Do they feel like, actually we got 80% of the way there? Is that worth it? I don't know. I think if you start to go into that, it's like, well, if you're not going to have a sprint goal that you pass or fail, then it's like, oh, well, why did you set that to be where it is at the moment anyway?

Yeah, and there's another angle to this, is this does not limit you to sprints and scrum as a framework. You've got it working across many Kanban teams. You've got it within communities that don't have any sort of time bound limitations. It's just a concept. We go time check, how's everyone feeling? That's it. And I think one of the angles you mentioned, like sprint goals value is one area that I did consider. At one point, am I working towards a specific mission or a vision or a specific customer proposition? Another one was got the opposite angle, autonomy. Is that something that teams want to monitor and check and say, we feel empowered to do what we want as long as it's aligned with our team goal. And I thought it would be useful to have in your back pocket as another petal on the whole flower thing, but it's not a requirement because some teams just don't need that.

No, I think that's where it starts to lean into looking at the spotify health check. If you want to add things in that's specific to your team, you should alter that it was created by someone else. Don't just believe it's all correct for you. And like you say with the petals thing, it doesn't have to be petals. It could be petaled. Put an extra letter, put an extra D on the end.

Petals acronym was quite convenient when I started doing the visual stuff, but I think that the visual aid of just having the other thing I tend to do with the scores is color code. So if it's a certain range, you can go, right, this is looking great. Let's have a nice green instead of a worried red. Or maybe you want to invert that. But you can add more factors to this. Right? And as I say, it's just the visual AIDS to have a conversation go, Whoa, that's an area I didn't realize there's an issue. Let's talk about it.

Yeah, you could see remote working or hybrid working, how's that working for the team? Here's an extra thing, right? You're going to get some people, oh, we really love that. We're now working 100% remote. Okay, but is that shared by the whole team? How's that working set up? Is that something that needs to be reviewed which then goes into, all right, let's have a conversation about it.

And actually, that's a good point. This was created with a remote team in mind. Doesn't work very well in real world because you need a lot of pieces of paper and calculations in the real time, so it works quite nicely as a pure remote option. You can do it with visual tools and reports and stuff like that, but you need a screen to demonstrate what you're getting back anyway.

I think it's mainly around the form submission, isn't it?

Yeah, there's data captured there, there's a bit of calculation on the back end.

That calculation bit, but you're not going.

To be able to live very easily just with your fingers or anything like that. Right.

It's the Blue Peter scale.

Totalizer.

Totalizer, that's what it is. Right. That's what you need to correct next, the in person totalizer, which has got five buckets. So I think with the submission thing, I think it's very good sometimes if people can come in beforehand of having submitted that or having that ideas in there, and then you get your totalizer out or you just view it on the web page and that's where you can really get into it. Agreed.

Something I've not really factored into this, though, you say that you can submit your scores and pick them up later. I tend to prefer it happening live as you go into that conversation because you can change within a few hours. You could sort of start the day and going, oh man, I've got nothing done. Then with a few hours going, Solved it right, I'm going to have that conversation now and oh, my scores are out the whack. But you can do that that way around. A lot of teams I've seen have said, just do it the start of the week and then we'll reflect on it next week.

Really? That's a bit of a weird far. Yeah. I was thinking mainly if you're going into a proper meeting room and you want to put it on a wall, start that retro off, that could be a nice way to do it.

I was speaking to someone the other week, they're doing that, they're going to capture the scores in the morning, print them all out to go into a pub retro to talk about it. Cool, that's a nice way to do it. You get a best of both worlds. You've got digital data capture and reports, you got in person conversation with real pieces of paper and pen. Again, it's just experimenting with this concept, but back to my point, do what works for your team. Not every team's the same. And as we've talked about previously, you can't clone team members and engineers and all this sort of stuff. Everyone's got their own preferences. You will have quiet people, you love extroverts, you'll have superstars, you'll have quite content people. It doesn't matter. But work out what works for the individuals and ideally have a good range. It's my point. What makes a healthy team? You don't want a load of clones. You want the diversity. You don't want all green every week because that's not going to look great.

Yeah. I think if you'd start to see green every week and that everyone's just content and happy, you'd be like, okay, are we pushing all of the buttons enough? Like, are we going fast enough? Is there more to be changed there? It's possibly too sweet. A Spot, from a business point of point of view, could say throw away.

Pells once you got to that point because it's not actually bringing you any value. Bring it back later if you think you need it.

Yeah. I'd start to sort of question if people actually caring and putting real results in there, or they don't feel safe, so they just put in a four or a five. True, easy way out.

That's another factor I've always considered psychological safety in a team. Are they comfortable talking openly about their feelings, engineers talking comfortably about their feelings? Really? I'm just playing to the stereotype here, but we're not the best at feelings side of things. As a manager, I might be more aware or I'll be observational, or I can go into coaching mentor in whatever modes to kind of make them feel better. They're not generally outward people. Most techies are introverted by default, I think.

Yeah, generally. But I think it's fitting in what the team works with the team. Like you've said, that it's not just tech teams that this works for. You could get a very open, fully social team that really want to get out of there and really put their names across to what their score is so they can share their feelings. And I think that's where you come to adapt it to fit the team.

Absolutely. So do you think something like Pels or actually, you mentioned the Spotify Health Check framework. Should we elaborate on that a little bit and see when that's relevant or useful?

So the Spotify Health Check, to give you sort of background on that, it was originally sort of created at Spotify. It was the squad health check model when it originally came out because they work in sort of squads instead of teams. It was a very sort of visual way for them to sort of reflect on the various aspects of team well ingaling, but it was also performance. And it was a traffic light system. Red, green, amber or red, yellow, green.

They're in there somewhere.

Yeah, it was good average, so so or bad. With speech that they go through, you could sort of pick, but the common areas were sort of like looking at code, quality, speed of develop, the speed of delivery, learning opportunities, mission purpose, team, fun, support from leadership. And my favorite was always Pawns or players. If they're doing teamwork or sort of working on their own, awesome. And then it really helped out. And the way I've seen it done a lot of times is sort of in retrospectives they'd go through and sort of everyone would sort of dot score on each of the categories and then over time you'd sort of look at scoring those and see where they are on them. And I've seen it works really well. The way I've seen also it worked there is putting in their own categories like hybrid working or remote working, what's working well. But it does focus on sort of the real technicalities of things. It's not just focused on the people and I think it's not strong into the people. I think people, when they see that quality of code, they very much go into technical mindset of getting into those things and not worried about how do I feel stressed wise? Well, am I learning? Yeah, you've got that. So I think it was looking at sort of improving the team over time. Keep doing it, seeing where the scores get to. Hopefully you can look at a section, okay, we're doing badly on support from leadership, how can we improve that going forwards? And it leans into being a different type of retrospective. Really?

Yeah, I've seen it used quite effectively in the past and I didn't have a problem with it. My main concern with it was it's quite demanding in time. So you tend to need at least 2 hours to have a retrospective around this health check framework. I think there's eleven factors you called out there and I've been in a situation where they've extended by two or three. So it's like almost 15 points. Conversation is really useful as always, but for me, because it was so long, they only did it every quarter and I was like, well, you're not getting that feedback loop that we used to keep talking about. You're not getting that the rapid recognition and observation, which is where Pel should complement something like this. Because I think the spotify health check has definitely got some interesting areas around like code quality and autonomy and value driven and stuff like that. What was my point on this? I don't know, I was just thinking it's a good starting point if you've never done one before. It's definitely a great conversation to have as a tech team, not squad. I hate that analogy. It's a team, but you can certainly identify some key areas. And that's the other thing. Dot vote on what the hot topic is for the team and then work out some actions off the back of that and then you can come back in three months time and go, right, how are we looking now? Which one's now most relevant now?

Yeah. And I think possibly, actually, if you split up, you're doing smaller sections, you group sections together. It can work if you've not got that full time, but yeah, also, if you do it every three months, it's like, okay, let's have a big retrospective on what's going on, how the whole team's going, what we're doing, what do we want to focus on in the next quarter?

It's a good off site exercise to have doing inverted commerce.

I've done a lot in pub retro.

Yeah. It doesn't happen all the time, but let's make it special. Let's do something a bit different and change the shape it up. The other thing, we talk about retrospectives quite a bit this time around. Retros can often feel dull and I've seen a lot of teams going, oh, yeah, we just have to do it, don't we? No, if you're not getting value from it, stop. But you probably should, and you need to shake it up. Bring in a new format again, petals, Spotify, whatever you've got out there, just try a different model just to change the conversation angle a little bit. Always comes down to the same old thing what's great, what's not, what we're going to do about it. But at least you're still having a conversation with different kind of lenses on it.

You're not going with Glad. Mad sad.

I never like that one. Stops. I'll continue. I was like, oh, really?

Four L's loved Laughed.

I quite like that one. And the rose one's. Quite nice. The thorn, the bird and the flower.

Yeah. We'll have to go into get an Agile Coach in and talk about retrospectives.

This would be definitely a dedicated episode. Like, what's your favorite retro model?

So next time, I think we'll come back with a more dedicated episode. Going into Petals, getting the backstory, how to use it, who's using it, and what's going to happen there of its future.

I'll tell you what, you can save me time and just go and listen to the Petals Snapshot podcast.

Yeah, but rival podcast.

Not rival, it's complimentary.

So where can people go if they want to learn more about Petals?

There is a dedicated website now, Petals Team, one of those funky new domains that work quite well for me, plus, was definitely not available. So, yeah, Petals Team has got, like, a brief overview of what it's all about. It's got a link to some Google toolkits you can use to start gather, capturing that data and analyzing it. I'm just adding bits here and there's a mailing list if you want to join, to find out what's changing and all the updates around it. So check that out if anyone's interested. I don't want to take over this podcast with it, but I thought the topic was quite useful. For the audience that we're trying to engage with on this podcast.

Yeah, and I think we'll do one next time, force you into talking about it in more detail. This is just the teaser that's been another episode of the Managing Engineers podcast. You can find out [email protected] or get in touch at [email protected].

That email is set up now, by the way. Rock.