Team Glue & Why QA is a Tech Leadership Role with Vernon Richards

What does it mean to be a "team glue"? Why does it matter? Why QA should be positioned as a tech leadership role?

Tune in the latest episode with the inspiring Vernon Richards to get the answers to these questions and so much more.

Find Vernon on:

• His website: https://www.vernonrichards.com/
• LinkedIn: https://www.linkedin.com/in/vernonrichards/
• X:  https://twitter.com/TesterFromLeic

Mentions and resources:

• Tanya Reilly on Team Glue: https://noidea.dog/glue 
• A conversation with Kanika Selvan (could not find yet her talk Pet to Threat): https://www.youtube.com/watch?v=Y0LY5iOZN14 
• On brag documents: https://jvns.ca/blog/brag-documents/ 
• Diary of the CEO podcast with Adam Grant: https://www.youtube.com/watch?v=uPXjt6beYbg

Follow Quality Bits host Lina Zubyte on:

• Mastodon: https://mastodon.social/@linazubyte
• X: https://twitter.com/buggylina
• LinkedIn: https://www.linkedin.com/in/linazubyte/
• Website: https://qualitybits.tech/

Follow Quality Bits on your favorite listening platform and Twitter: https://twitter.com/qualitybitstech to stay updated with future content.

If you like this podcast and would like to support its making, feel free to buy me a coffee: https://www.buymeacoffee.com/linazubyte

Thank you for listening! ✨

Transcript

Copy Transcript Copied

00:00:04 Lina Zubyte 

Hi everyone, welcome to Quality Bits - a podcast about building high quality products and teams. I'm your host Lina Zubyte. 

00:00:15 

The term team glue was something that I liked from the first moment I heard it. Being a QA, I could truly resonate with “building bridges” and “glueing” certain parts of the system together so it works overall. So, in this episode I'm talking to Vernon Richards about the concept of team glue. You're not only going to learn what it is, why it matters, how can we encourage it more, but also why Vernon thinks that QA is a tech leadership role. Enjoy this conversation. 

00:01:03 

Hello Vernon, welcome to Quality Bits! 

00:01:07 Vernon Richards 

Hello, thank you for having me. I'm excited. 

00:01:10 Lina Zubyte 

Thank you for joining me. Could you shortly introduce yourself? 

00:01:14 Vernon Richards 

Yeah. So greetings, my name is Vernon. I am a quality coach based in the United Kingdom. By day I work for a health tech company. My job title there is amazing: Senior Expert Quality Engineer! Thank you very much. And then outside of that, I do a lot of training and speaking at conferences and hosting things. And, married, three kids, life is good. 

00:01:39 Lina Zubyte 

So the concept I would like to talk to you about today is glue work. We may have heard about this before, but how would you define glue work? What is it? 

00:01:51 Vernon Richards 

Well, it's a term that I heard from the legendary Tanya Reilly. You should definitely check her out on socials. I describe it as the work that needs to happen in order for a project to succeed, but isn't actually anybody's official responsibility to do, but if it doesn't, like I said, if it doesn't happen though, the project is much more difficult and probably may not even succeed. That is how I define glue work. It's the work that falls through the cracks. 

00:02:22 Lina Zubyte 

Oh, it sounds like the QA job for me. 

00:02:25 Vernon Richards 

Well, yeah, we'll get to that, I think. There is some relationship between glue work and certainly quality engineering - how it's described by a lot of people. I think there's definitely a relationship there and so I can get into that at some point during this conversation, no doubt. 

00:02:42 Lina Zubyte 

So what kind of work usually does not fall onto anyone's responsibility? What could be some of the examples? 

00:02:50 Vernon Richards 

So, for example, you might have a teammate who is working on something, a feature, or something related to the Sprint that you're in, and they may be struggling to get somewhere. Maybe they need to go and interact with a third party who's not in the organisation, or maybe it is somebody who's in the organisation but not on your team, so it's another, an adjacent team to yours, and they're battling. They're trying to get what they need from this third party. But it's not working. So in that situation some glue work might be: how can I remove the friction from that conversation or interaction so that my teammate is kind of unlocked and released? And can I just go and deliver the work super fast? So that's an example of glue work. Another example of glue work might be, say liaising with a customer or a client. 

00:03:39 

You might have committed some work in your Sprint or your iteration or whatever, or your cycle, whatever it is. And you're getting on with that work and then out of nowhere there's a customer need that comes from somewhere. Maybe there's an incident or some kind of production issue and someone needs to jump on that. You know, you could also class that as glue work. So how can we keep this customer happy without disrupting what we're doing within our Sprint? There're bunches of examples, I think. 

00:04:05 Lina Zubyte 

One of the examples I could think of right now, which actually was more like structuralized you could say, is having some kind of hat just for a week saying I'll have my OPS hat, we would have OPS hat in the team and then that person would be the person who would be answering any kind of requests from other teams or navigating to whom this task should go to. And this role would be rotated. Would that be considered glue work? 

00:04:39 Vernon Richards 

I wouldn't call that glue work, I don't think, because that to me feels like you can't ignore it. If it's your responsibility in a given rotation, I think it would be difficult for you to kind of say: “ohh this has got nothing to do with me. I'm just gonna let it go.” I think one of the properties of glue work is you could legitimately ignore it by saying “this is not part of my job” and another property of glue work is related to that first point is: when you do do it, you may not always get the recognition for it because it's not part of your job officially speaking anyway. It's not explicitly “Oh, Lina, you must go and take care of this customers.” You might just see the need. You might just be getting on with your own stuff, and then it's, oh, there's a problem over here. Let me just go and solve it. That's glue work. Think of it like housework as the dishes pile up in the sink, it's that - that's glue work. It's that thing. Well, eventually we're gonna run out of dishes and cutlery. Who's going to clean them? And it's like, you know, they're just piling up, piling and piling and piling and piling up. 

00:05:43 Lina Zubyte 

Yeah, but that could be, you know, the whole family eating and then they all produce those dishes. And then if you have the structural role, you would avoid it so that nobody feels like they have to do the glue work because they did certain process. However, we still have lots of glue work. So now I'm trying like to somehow like share the load of the glue work by making it a process, but why does glue work matter and are there ever cases where we don't have glue work or we always will have it? 

00:06:15 Vernon Richards 

Well, here's why it matters, and this is what got me interested and this is what set off on the few light bulbs for me. If you think about some of the examples that we talked about, imagine that you or I were kind of in sticking our nose in to do this glue work or taking responsibility for doing the glue work. I'm a QE in my particular day job right now. Sometimes that would be seen as me interfering because I'm coming at it from a QE position. I can say hey from a software delivery perspective, all these dishes are starting to pile up. We need to sort that out. I'm gonna go and do that or I'm gonna arrange for the team to go and do that and deal with all the friction and their reluctance and all the rest of it, but... 

00:06:59 

I agree with Tanya Reilly, who I learned this term from and she positions glue work as technical leadership. And if you imagine anyone with any kind of leadership, official leadership, with a leadership role, so I'm talking about like an engineering manager, a staff engineer, anything like that. If they went and said to the team or remarked to the team, pointed out to the team: “Hey, this thing over here is not working. I'm just going to go and do it or one of you needs to go and sort this out because this is a problem.” There would be less friction. In some cases, there'd be 0 friction, no one would ask any questions why the engineering manager was involving themselves in the story refinement process because the stories being refined, the quality was not good, which had an impact on the rest of the delivery. No one would say, oh, that's weird. No, stay out of it. This has got nothing to do with you. 

00:07:51 

Whereas sometimes as a quality engineer, people might look at your role and say, well, you're a quality engineer, why are you getting involved in story refinement. Why are you getting involved in setting dashboards for observability or monitoring? Like just go off, go away and go and interact with the product and just look for bugs and just do that. You know, write some selenium scripts or whatever. And so that's why I think it's important and useful because really at its core, its technical leadership. And that's important. Like, we need technical leadership. We need people who are going to take responsibility for things that are, quote on quote, “not their job”, but make everybody else succeed. That's an important thing to do. 

00:08:34 Lina Zubyte 

So when you were reading Tanya's article and learning about this concept, you were a quality engineer, right? So how did this all make you feel and how did it help you knowing about this concept? Because you still explain quite a frustrating situation, right? You try to make a change and then you don't have this tech leadership in your title. 

00:08:56 Vernon Richards 

The frustration was key, and so there's another concept called Quiet Quitting. And quite quitting is that phenomenon when you're going above and beyond your job just normally, because that's what you do. Generally, people in in knowledge work roles, that's not uncommon for people to do that. But with quite quitting, you're doing that, you're putting in extra time. You're putting in extra effort, you're going above and beyond your role, or at least you believe you are, but you're not getting the recognition or the reward. Whether that's a pay rise, whether that's a promotion, whether that's just a simple thank you. And you start to realise this is not in my best interest to keep doing this. I'm putting in all this extra effort, so I'm not going to do it, and so you quiet quit. Now that isn't you completely down in tools. It's just saying your job description was this, I'm making a square shape with my fingers for people who can't see this, that's your job. But you've been working way beyond that, OK? 

00:09:59 

And so what you do is you bring all your focus on your energy and you constrain yourself so, you know what? If I'm only gonna do exactly what's in my job description, nothing more. I'm not gonna do less. I'm definitely not gonna do less. But I'm not gonna answer that e-mail at the weekend. I'm not going to just check to make sure that the site is up. I'm not going to work late every night. I'm going to start when I'm supposed to start. I'm going to finish when I'm supposed to finish, and I'm going to do everything that's in my job description and that's what quite quitting is. Now, what does that have to do with quality engineering? 

00:10:33 

I'm pretty sure some of the examples that we talked about in terms of glue work, there are a bunch of people listening to this who go “wait, I definitely do that in my job as a quality engineer”. My quality engineering role, the expectations my teammates have of me and my line manager isn't just to interact with the product and look for bugs. It's also to look after the quality culture. It's also to go and have conversations with anyone and everyone to try and improve the quality of the product and the culture at the company. But we aren't positioned as technical leaders, we've positioned as testers. So when we start showing up in conversations or pointing things out, say, Oh I think if we did this all these things would get better, or I think if we, you know worked on the quality of our stories, all of this stuff would get better. 

00:11:21 

If we worked with this particular customer, all of these things would get better and so on. People are sometimes like, why are you worrying about that? You're just quote (air quotes), just the tester. And so I think the way around that is to acknowledge that what we're doing is glue work. But if we acknowledge that what we're doing is glue work. What we're saying is our role is a technical leadership role. And we need to be positioned as such by you know, the people that bring us into the company, they should position us as technical leaders and there are things that we can do individually to position ourselves as technical leaders. But I think it's easier done at the outset when you're brought into a team with the expectation of disrupting things, and I learned from a friend of mine called Kanika Selvan. We're recording this the week after International Women's Day and she had a talk called “From Pet to Threat” which resonated with me a huge amount. It also reminded me of this phenomenon of you're brought into a team to disrupt things, but when you start disrupting things, suddenly everybody's got a problem with it. I think there's a relationship between those things. 

00:12:31 Lina Zubyte 

You know Jerry Weinberg said that the consultant is a jiggler, that you go to jiggle things in the team, and I hope I'm quitting it, right, actually. I think it is the jiggler.That’s the term. And it's sort of almost like a game avatar or your role because you are supposed to do that. But when you are hired to sort of just do your job, do your boxy thing, then it's, a little bit like... people may look at you and say, hey, what are you doing? You're not supposed to be the jiggler here. You're supposed to be this box that we assigned you to. 

00:13:10 Vernon Richards 

Correct. Yeah, that's exactly it. You know, stay in your box, tester! That's how I usually frame with people. And the positioning is all wrong. And so that's the thing to battle. And the talk from Kanika Selvan called Pet to Threat. It talks about this. Kanika was talking about it in respects to being a black woman in tech. You're brought into a team because you're going to bring diversity of thought and diversity of opinion, and everyone's excited at the start. But then, as your diversity of thought and opinion and action starts to manifest itself, which is what you were brought in to do, everyone was excited. As soon as you start to do those things, suddenly people like, well, well, well, well, what? What? You're disrupting things too much. Let's simmer down, please. Like calm and everyone's like now it's a problem that you're thinking different. It's a problem that you have a difference of opinion. 

00:14:00 

And it reminded me hugely of being a quality engineer. You know quite often you’re brought in because the testing isn't, you know, we're not happy with the testing and the quality culture here is not so great. And we wanna, you know, change things up and stuff. So it's like Lina is coming in. She's amazing. She's gonna do this thing. Go get them, Lina. You're amazing. And then you start doing your thing and suddenly, you know, people are grumbling. Now why do we have to do these unit tests? And why do I have to do all the test automation now? This is not part of my job... Grumbling, oh, why is Lina going over here and talking to you know, the OPS people that, you know, she's a tester, shouldn't be involved in all those things? Grumbling and grumbling. 

00:14:37 Lina Zubyte 

Yeah, everyone has their own idea, right, of what that role means. And then when Lina goes and checks the pull requests, they're like, why are you looking at the code? You're supposed to just test the black box way. 

00:14:50 Vernon Richards 

A 110%, which is why it's a matter of positioning and it's a matter of support. It needs to be so unequivocal that we are being brought in as technical leaders. I saw a tweet. I won't use her name. Let's let's call her Gem. Gem is on the surface at first glance anyway, you might think that Gem is an automation engineer. But in my book, whenever I read her tweets and stuff, she's a developer that really likes testing. But because she's positioned as a, quote-on-quote, just a tester, whenever she tries to do these, poking into the PRs is a great example, because I'm sure I've seen a tweet about that: people are wondering why she's doing that. Another thing that she tweeted about recently was, I think it was, retros. What she described was the product owner is going to run the retro and there's little to no engagement from the developers in the team. And then Gem has tried to run the retro. And again, there's little to no engagement in the team. But then, lo and behold, the company hires a principal dev, a staff dev. And they run the retro - basically the same process, nothing is different, but now it's a principal dev (may or may not be a DET, I don't know). But now, suddenly, everyone's enthused. Everyone's engaged. Everyone wants to get involved now and it's like, well, that's again, that made me think of this is a position it or at least part of this situation is: this is a positioning problem. And it just reminded me again of glue work. 

00:16:26 

So yeah, I think how it's positioned, how the roles are positioned within teams is important. And like I said, some of that... I don't want to. What I'm not saying is that quality engineers are helpless and must be saved and rescued, and all of it. I'm not. That's not what I'm saying. Yes, there are things that we can do as individuals to make this better and easier. What I'm also saying is that the leaders. So I'm talking about EMs, VPs of, directors of, Chief X Os, like whatever they can do a much better job of positioning this role within their organisations. So that there's less friction when people come in and to your point, which is exactly the point. It sets the expectations at the right point. And they should be prepared to provide air cover. I like to say air support for the people that they're hiring. 

00:17:22 

So let's say it's a director of VP of. They should be going to their peers across the business and saying, hey, I've just hired Lina. She is gonna be everywhere and it's like you should expect to see her in meetings that she might have been invited to. Or you're the VP of engineering and maybe there's a VP of product... Don't be surprised if Lina shows up in your part of the business saying, hey, here's how we can do things differently. And here's how we can do things better because that's her job. She's here to try and affect the quality in the whole organisation, and she's just gonna follow that thread wherever that leads. So I think there could be more of that and there should be more of that. 

00:18:02 Lina Zubyte 

I really like that it's basically on leadership to position the role, so it's set for success. It reminds me of those cliches, sayings like fish rots from its head. 

00:18:16 Vernon Richards 

Ah yeah. 

00:18:17 Lina Zubyte 

I truly felt in my career sometimes that my role was sort of building bridges which you could classify as glue work. And being “just a tester” was quite painful sometimes because I wouldn't be invited where I should be. I would miss out on information and I would find myself in this quiet quitting stage actually. 

00:18:44 Vernon Richards 

Yeah, a lot of people I've shared this idea with... It's resonated with a lot of people. Quite quitting is, or just straight up quitting and leaving the industry altogether - that's not what we want, because think about it. You've found someone with the right stuff. In this case the right stuff is - they are willing and able to go and build those bridges, cause that work is hard and it's long and it's time consuming and it's energy draining. But nonetheless, people look for it because they recognise the benefit, but then they're discouraged from doing it. And almost to 1° or another chased out of the organisation or it soon becomes clear that this company doesn't value the things that I bring to the table. Maybe I should go and work somewhere else and it's so difficult to hire people. Why would you want to do that? 

00:19:34 

Particularly, in a role that is effectively a technical leadership role, why would you do that? That's very crazy. That's on the downside. Sometimes people, and I'm seeing more and more of this, people who are quality engineers who started off in the quality engineer role, what they do is they switch so they try and pivot to an engineering manager role, or they pivot to an SRE role, or they pivot to a platform engineering role or a developer - they find some way to get out of the testing role because in this testing role, this quality engineering role, some companies prevent you from getting access to the levers that you want and you need to pull in order to help improve the quality. But if you're an SRE, quite often they'll give you access to the levers. If you're a product owner or product manager like hey, of course you can have access to all the levers, please do. Engineering manager – same, and so that is something that I'm seeing at least in the people that I've met in the industry and I've been in the industry for over a couple of decades. So that's probably also part of it because some of the people I've known have been doing this for a while and you know, just promotion and rising up the ranks, if you like, is often part of that process. But some of these people... You know my 2 favourite examples are Alex Schladebeck and Vera Baum, both in Germany weirdly enough. 

00:20:58 

When I met both of them, they were some kind of consultant/tester in a test consultancy and they're now both the CEO's of their company. Or the Co-CEOs of their respective companies. But they're not the only example so that you know, there are people I know who are VPS of now and directors of engineering now and principal platform engineers in startups, you know (shoutout Abby Bangser) and everything in between. But they've left quality engineering. Why? Because it's easy to do your job if your title is Developer, Site reliability engineer, director of engineering, engineering manager, etcetera, etcetera, etcetera, etcetera and it's good for them on a personal level. But it's also I find it quite irritating. There's a part of me that's irritated that they had to do that in order to become effective, but it's not true of everybody who does that. I'm not saying that is the explanation why these people have risen up the ranks on its own. I'm just saying for some people that was an explicit choice. Like I need to get out of testing so that I can actually make the impact that I need to make. That is definitely true. 

00:22:02 Lina Zubyte 

And also you cannot really get out from this tester label while trying to find a new job because you may need to do it within the company you're working at because they know you and otherwise, why would someone who has worked as a tester be able to be an engineering manager? Well, they would be able to be an engineering manager and likely a good one. Let me tell you that. 

00:22:29 Vernon Richards 

Ohh boy, yeah, now we're getting into some topics now. Yeah, it's that transition into an engineering manager role, let's say, is annoying. Same with moving into a development role that can also be irritating because people look at the role and they don't see any overlap or any possibility that someone with a history in testing could be an engineering manager. It's wild. I don't know what some of these organisations think an engineering manager does, but it's not a hands on role. My opinion about this is that it is a career change. When you go from being, you know you move up the ranks in development, you know, Dev, senior, staff. And then you go to engineering manager. I think that's your first moment when you take your hands off. “Off the tools” we have a saying in the UK, if you're on the tools, it means you're it means you're hands on, you're at the coal face, you're doing the work, you're on the keyboard, you're in the IDE, you're doing the work, I would argue that an engineering manager isn't doing that, and if they are doing that, it may be, generally speaking anyway, maybe there's something, something has gone wrong there. 

00:23:40 

So there's an expectation that an engineering manager is supposed to be able to code quite often. And I don't think that's true. I think they have to... Same with testers, actually. I think there has to be a level of technical competence and understanding, but what that means and what that looks like is very context specific and it isn't always synonymous with coding, which I think is what the industry at large seems to do: technical equals coding. And I don't think that's accurate. And because it's a change of role. Then my opinion is that it's a whole different skill set that you should be worried about, and you should be thinking about. OK, what is it? What does success look like for this engineering manager? Are they succeeding if they're doing a lot of coding? I would argue no. Leadership isn't about coding, it's about amplifying and supporting people. And so that's what I’d be thinking. 

00:24:41 Lina Zubyte 

I think also that the way we shape the role of a QA or tester frequently is quite harmful because we do put them in the boxes and there are lots of people in the industry who are totally fine writing Selenium tests all day. I would go crazy. But then this is where I find myself that... Come to think of it, each time I was interviewing a QA, I was looking for someone who's good at glue work. I was looking for tech leadership and I would be frequently annoyed because I would interview a person with 15 years of experience who hasn't left their silo in a sense. They still were in their booth. I'm not talking to anyone, and they were happy with that. So yeah, I think a necessary condition for a good QA in my head is glue work. It is tech leadership. That's how I see the role. But not everyone sees that role this way. 

00:25:42 Vernon Richards 

I couldn't agree more. So, as you said, is there value in someone, quote-on-quote, sitting in their booth with their noise cancelling headphones on just churning out Selenium or Cypress or Playwright scripts? Yeah, I guess, I guess. I guess there is value in that, but how much more effective would they be if they lifted their head up and had a scan around? And actually interacted with their teammates and the business and said... Well, which parts of this application need scripts? Where can I leverage my code writing skills to add even more value? Perhaps there's something I can do to improve how we release this product in this software for example? Or who do I need to go and talk to figure that out? OK, cool. And you often have that conversation, or how are my automation scripts? How can I leverage those in production somehow? I know that's not the most optimal solution, but maybe it will solve a quick problem quickly and then we can then we can iterate on it later? Then we go and talk to the my pals, my OPS pals or my data team and see what how that might impact data. 

00:26:54 

So I couldn't agree with you more. I also when I'm hiring and looking for teammates, I'm looking for people... If they are from a testing and quality background, I'm looking for that technical leadership glue work type skill set. Obviously you need that kernel of skills in testing, definitely like can you interact with the product to find problems that is important for sure, but you can leverage those skills with glue work to amplify them. If I'm involved with hiring a dev, I want to see glue work and I want to see a willingness to collaborate with people who are not developers, who don't spend most of their time in an IDE, but they want those conversations with those people because they recognise that that helps them more effective in their work. Glue work is all around us here in the software development and particularly in the software testing and quality space. 

00:27:51 Lina Zubyte 

I feel like for me, a perfect team is quite good at glue work overall. Almost everyone is: they're proactive, they're collaborating. They're curious about each other. They know that they can learn more things from each other. 

00:28:07 Vernon Richards 

That’s the word – curiosity. Come on. Yeah, it's like. What thing? That's weird. It's that feeling of that's weird. I did a tweet a couple of years ago that tried to describe this because here's what I've noticed with the people that I think have been amazing testers and it's basically what you said. It's curiosity, so you start off, you join and you're like, I'm just gonna interact with this product to look for problems. However, I'm gonna do that when I use a tool like a GUI automation tool, an API tool. or I'm, you know, quote on quote, manually testing. I'm interacting with a product but it doesn't take long before you start to say things to yourself and to your team like this. You start say things like... 

00:28:52 

Man, this would be easier if I didn't have to create this test data all the time, quote on quote, by hand. If we could automate that, I could just spin up some just get some test data and then get rid of it quickly. That would be amazing. Or you might say things like you know, if these stories were in were in better shape, the delivery would get better because we'd all know what it was we were building and we could have an idea what dumb looks like. Or you say things like... You know these... If we could test this in production because all the data we want. We could possibly need is in production like. How can I get access to that? And guess what? All of that is... you're now going into beyond the test. You know the, quote on quote, testing. You're now doing a little bit of glue work. It would be easier if. Oh, wouldn't it be better if this problem was gone? Wouldn't be a problem if we had this capability? Now you're starting to demonstrate technical leadership. 

00:29:42 Lina Zubyte 

Side fun fact is that curiosity I feel is like a base of a tester in a sense and I just realised recently that I have one picture of myself when I was 3 and I am holding a bug and it's of course broken because I was curious enough to break it. So, my mom still remembers this. And she's like, yeah, no way. You're actually working with this. 

00:30:09 Vernon Richards 

Yeah, it's one of those roles, or at least when I started, was one of those roles that people... If they went into it deliberately like I did, the goal was not to stay in that profession. It was a stepping stone to something else. Or you just fell into it accidentally. You know, you were in a company that was building a thing. You had some domain expertise. And so people were like oh, hey Vernon, you know, you're a cashier in a bank and we're changing all of the software for that cashier role on the on the terminals. Can you help make sure that the new thing we're building is alright? Like, OK, yeah, it's not. Start getting into it. So like, oh, this is pretty sick. I'm working this software around. That stuff is alright. Can I stay? I've heard a few people talk about things like that. 

00:30:57 Lina Zubyte 

Actually, there's lots of interesting things in the QA role. This is why I also really like this role. Yet this title or label is sometimes annoying because it can somehow stop you from doing things that you want to do. Because I love glue work. I do think I'm good at it. I do think it makes our products better quality in general that we're building more efficiently and faster even. How can we encourage this glue work though in the teams? Because when you build a feature, it's very tangible, right? There's a feature. Here you go. I built it, but how do you not go into quiet quitting while doing the glue work? 

00:31:39 Vernon Richards 

Ohh, fantastic question so I will steal some advice from Tanya. Forgive me, Tanya, if you hear this, but definitely I recommend going finding.... I suspect Lina's going to put this in the show notes, but there’s an excellent resource from Tanya where she literally has a link to her delivering the talk. There's like transcripts of the talk. There are slides of the talk. It's all laid out. So I'm pretty sure she'll give you that link. But in there, some one of the things, I wholeheartedly agree with, is: you need to make the work visible and you need to speak to your line manager and really set the expectations and say... From your point of view, what does success look like in this role? That will start a dialogue, no doubt, and I would encourage people to not be passive in that conversation and kind of say, well, here's what I think it should be. 

00:32:33 

And see if you can come to some kind of agreement with your line manager, because ultimately that is one of the downsides of glue work is that it's not recognised and it it's somewhat invisible. So try and make it visible. Related to trying to make it visible, I think there are things and this is something I need to write more about and speak more about and investigate more. Weirdly enough, I think if you look to the entrepreneurship space, there are a lot of solutions to this making glue work visible, and that is one of those is building in public. So don't be shy about sharing what you're doing with your teammates. Make it visible, make it public. In your team slack, just kind of almost all in your dailies kind of say, hey, here's what I did. Create almost like a journal somewhere in confluence, let's say, and share that with people on a regular basis, including your line manager and maybe even their bosses as well. 

00:33:29 

And when you're taking on a new role, you need to be extremely explicit if you like, with your hiring manager. And maybe their peers, if you get a chance in the interview process or if it's an internal move with their peers. Kind of say I need you to position me like this with the team that I'm going into. Now you need to position me as someone who's going to be doing technical leadership work. And isn't necessarily going to be hands-on the tools, interacting with the product all the time. I'm looking at it from a more strategic point of view and I'm trying to make the team more capable. 

00:34:07 

So yeah, I would follow that advice. Speak to your line manager, look to the entrepreneurship space, because that will teach you things like marketing and positioning and understanding who your customer is and trying to, you know. You are ultimately selling yourself. It's a sales process, so you need to understand well what problem is my role solving and how are people solving it right now and how am I going to do it differently? And then make sure that your line manager and their peers and maybe even their boss is positioning you properly and effectively before you take the role to hopefully head off some of all these challenges with people being surprised that you're involved in certain topics. 

00:34:53 Lina Zubyte 

The frustrating part here is that sometimes you may be doing the glue work for your manager because they don't know about the glue work. 

00:35:02 Vernon Richards 

Yeah. 

00:35:02 Lina Zubyte 

And you're like again, I'm doing all this work to be recognised. 

00:35:07 Vernon Richards 

Facts. Some of the best advice that Tanya gives is to stop doing glue work and to essentially quiet quit. It's how I interpret it. It's not the word she used, but she says. Yeah, stop doing the glue work. If you're not getting recognised for the work, stop doing the glue work. I think that's good advice. The challenge for people in the quality engineering role is that glue work is the job. If I completely stopped doing the glue work, I would probably have to actually quit because the job would become so dull and I'll have to find somewhere else, but that is a legitimate tactic. Her talk was positioned to, I think, coders, people who are in IDEs all the time. But I think it does apply to quality engineers, but there's a bit more risk there for us because I believe most of our job is glue work. 

00:35:57 Lina Zubyte 

Absolutely. Another resource that I thought of when you were telling to write like a journal of what you did. There's a concept of a brag document. Usually it's the private one, but you're writing down what you did. I especially recommend it to people who are struggling sometimes to recognise themselves. Like put this into your brag document. Recently I wrote a compliment to one of my colleagues and she said, you know what, this is going directly to my brag document. Thank you so much, you made my day. 

00:36:27 Vernon Richards 

Brag documents for the win. Amen. Some friends of mine, David Williams and Dan Ashby came up with this idea of an impact map, and it's just this way of capturing what you do every day. So it basically creates a brag document that you can then use when it comes to, you know, your review conversations or your promotion conversations and your pay rise conversations and it ties all the good things that you describe that your teammate grabbed and put in their bag document. And it also positions it in terms of what kind of impact did you have with who? What did you do? What was the impact still in there? I think brag documents are absolutely the way forward and that's something that I need to do a better job of because I was in a really good habit of doing that a couple of years ago. And I have failed to do that over the last couple of years. I need to get back on that. 

00:37:18 Lina Zubyte 

Me too. I need to write down more what I’m doing because I'm like, oh, I'm not sure. So we are going to add all these resources that we're talking about in the episode notes and to wrap up this conversation, what is your one piece of advice for building high quality products and teams? 

00:37:39 Vernon Richards 

Ohh. I've learned a new term. I was listening to an episode of Diary of a CEO with Steve Bartlett. I know some people find him a little bit annoying, shall we say? Well, he had Adam Grant on recently and I see the world in terms of basically everything reminds me of software testing and software quality and coaching, and this episode was no different. Adam talked about this concept of a challenger network. So, similar to a support network, a support network is essentially, I think the words he used at some point were like cheerleaders, but like no matter what you do, they're like, no, you've got this, you're absolutely incredible. No, it's amazing, but a challenger network is more like a group of people who are there to critique what you have done, but because they want you and or the company and or the product to succeed. 

00:38:34 

My advice to companies and individuals would be to develop and nurture your Challenger network and guess who the Challenger network reminded me of in terms of roles on a team? That's right. Quality engineers, testers, AKA your technical leaders. And I've met some people who are, what did he call them? It was something like here's the term that it reminded me of, it was like people who were grumpy. But they're grumpy because they're frustrated that things could be so much better and they're keen to make them better. And some people like my dear friend Patrick Prill, the inspirational Maaike Brinkhof and my brother, Martin Hynie, to name but three. And of course, Del Dewar, they reminded me of this. They're grumpy. But sometimes the grumpiness is because they want things to be better. So develop your challenger network, and if you're in a company already that's building software, you have people that are predisposed to do that, and that's called your quality engineering function. So go and turn those into your Challenger network. 

00:39:44 Lina Zubyte 

Oh, I love that I always had a place in my heart for the grumpy people. So now I know why. Because the grumps - they care and I like people who care. Thank you so much for this conversation. This was wonderful. 

00:40:01 Vernon Richards 

Thank you so much for having me. Great questions, you're an amazing host, so thank you. 

00:40:06 Lina Zubyte 

That's it for today's episode. Thank you so much for listening. If you like this episode, like, share subscribe, check out the episode notes and until the next time do not forget to continue caring about and building those high quality products and teams. Bye.