Ever joined a new company? I bet. The start is always challenging, and as Angela Riggs says "you have to learn to learn".
In this episode of Quality Bits, Lina and Angela discuss the feelings you may face in a new workplace, the job of a QA manager, setting boundaries, and management practices which support the high-quality product building teams.
Find Angela on:
- Her website: https://angelariggs.github.io/
- Twitter: https://twitter.com/AngelaRiggs_
- LinkedIn: https://www.linkedin.com/in/angelariggs/
Resources:
Links to books are to Amazon and as an Amazon Associate I earn from qualifying purchases
Follow Quality Bits host Lina Zubyte on:
- Twitter: 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.
Thank you for listening!
Ever joined a new company? I bet. The start is always challenging, and as Angela Riggs says "you have to learn to learn".
In this episode of Quality Bits, Lina and Angela discuss the feelings you may face in a new workplace, the job of a QA manager, setting boundaries, and management practices which support the high-quality product building teams.
Find Angela on:
- Her website: https://angelariggs.github.io/
- Twitter: https://twitter.com/AngelaRiggs_
- LinkedIn: https://www.linkedin.com/in/angelariggs/
Resources:
Links to books are to Amazon and as an Amazon Associate I earn from qualifying purchases
Follow Quality Bits host Lina Zubyte on:
- Twitter: 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.
Thank you for listening!
Lina Zubyte (00:06):
Hi. Welcome to Quality Bits, a podcast about building high quality products and teams. I'm your host Lina Zubyte. In this episode, I talk to Angela Riggs. Angela is a QA manager who is working in a pretty interesting setup. She is working closely with an engineering manager, which for me totally makes sense, right? So there's lots of overlap with QA activities as well as engineering. And we discuss learning how to learn when you join the new company, sharing the responsibilities, and as well how you tackle this quality mindset in teams and what makes a good manager, or how we can inspire our teams to build better products.
(01:07):
Hi, Angela. It's really nice to have you on Quality Bits. Welcome.
Angela Riggs (01:13):
Thank you! I am super excited to chat with you.
Lina Zubyte (01:16):
So nice that you're excited. I am as well because I have followed you for quite a while. We met because of QA community, right? Speaking at conferences. And I really find you to be a very pleasant and conscious voice in the QA community. So could you please tell listeners a little bit more about yourself?
Angela Riggs (01:43):
Yes. So currently I'm an SDET manager for a platform team at Sonos. I've been in quality engineering for most of my career, although I did start as a developer intern when I first made the switch away from teaching into tech. Outside of work as sort of hopefully the tail end of the pandemic, I'm starting to enjoy traveling with my spouse again. I get to spend a lot of time with my niece and nephew and over the pandemic, as many of us have picked up different creative hobbies, I started loom weaving and weightlifting.
Lina Zubyte (02:18):
So you mentioned that you're currently a QA manager. What does your regular day look like as a QA manager? Is there even a regular day? What are your responsibilities?
Angela Riggs (02:30):
Yeah! So I think in general, the day-to-day is probably the day-to-day of any manager, right? So general sort of responsibilities are, you know, working with the rest of my quality org within the platform group to define and implement our quality vision, supporting team growth and individual growth. Setting context for my team, I think is a huge part of being a manager. And then, you know, at a high level, creating an environment and a culture where people can succeed in the work they're doing, in the work that they want to do. Yeah, those were the high levels sort of day to day. More specifically probably as, as QA, a lot of it is sort of just staying up-to-date, making sure I can remove any blockers for people, you know, communicating, making sure the avenues are in place for other people to communicate and work together well.
Lina Zubyte (03:22):
I really like you mentioned, removing the blockers. I find the bottlenecks and making the work more efficient is one of the essential parts of the QA role that we sometimes forget or neglect. So it actually hasn't been that long that you've started your new job, Is that correct?
Angela Riggs (03:44):
Yes! I'm just under two months.
Lina Zubyte (03:47):
Oh, under two months. So it's pretty humbling usually when we start a new job, because I remember when I started my job, I was sleeping so well the first month because at five I just had to turn everything off and just digest all the information I collected. And I also realized that, you know, I don't know much yet, and now like I'm two years in this role, and finally I start getting some of the domains and some parts that I never understood before. How is it for you? How is it being in this new position so far? Do you have any learnings there?
Angela Riggs (04:27):
Yes. Humbling is a good word. You know, like a lot of times you start a new job, you have a, you know, 30-60-90 day plan. But this is - you know, there's a lot of new things about this role for me. It's like, you know, cloud team, it's a platform team. It's a direct reporting structure versus a matrix reporting structure for me. So I'm responsible for a lot more and for knowing a lot more. And so the first few weeks are really good, like, it's a very broad learning. And then you start to sort of uncover all of your unknown unknowns and now you sort of realize like, Oh, there's so much I actually don't know and kinda need to know. And it's kind of like you said, it's very humbling, to sort of start making that switch.
(05:13):
And it's progress. You're always going to hit that point of conscious incompetence where like, you know, how much you don't know. So I'm in the process of moving through that, and starting to get more confident and like, okay, I know what I need to know. Let me go learn it. You know, I keep hearing - people keep telling me, six months. Like at six months if you're really starting to grasp, you know, that, domain knowledge of your organization, that'll be great. And six months sounds like a long time, but I'm about to hit my two months. I'm thinking like six months actually sounds reasonable. And so I'm trying to be very kind to myself about that.
Lina Zubyte (05:50):
Absolutely. We have to be kind and remind ourselves that, you know, we don't know everything; and time teaches us more and more about the context we're in. I actually remembered this concept of the blue tape list. Are you aware of it?
Angela Riggs (06:06):
No. What is that?
Lina Zubyte (06:07):
So, I think the person's name is Rands and he writes about leadership and he wrote the book - it's a nickname, Rands. So Rands wrote a book, The Art of Leadership and the Little Lessons about Leadership. And one of the articles is the blue tape list. It basically states that when he had a reconstruction in his home, there was first this some kind of facade so he could not see the work that the workers were doing. And then eventually they removed it and then he saw so many imperfections. And he started getting frustrated by it, you know, and he was building resentment over all those things that had to be changed. And one of the construction leads just gave him a tape. He gave him the blue tape and said, If you see something, you want to get it fixed, just mark it and note it with this blue tape and we'll take care of it.
(07:07):
And he did. And he uses this metaphor of the blue tape list in work as well, or life. So he says that at the start of a new job, it's very nice to create a blue tape list - meaning that we note down all the things that we think are not okay; and you collect a lot of things when we start the new job, right? So a lot of things are not okay the first month. We shouldn't really try to solve it because I think that's another thing, right? We may want to be useful from the start. And then with time we get more and more context, we understand better why certain things are certain ways, but then one by one we can actually go through this list and start solving them. So I really like this concept actually. I think it's a nice way to start a new job and I always ask QAs in the company who joined to create a list like that because we start taking things for granted. We don't see through those fresh "new joiner" eyes after a while.
Angela Riggs (08:06):
I love that metaphor!
Lina Zubyte (08:08):
Yeah. It's such a nice concept. So I guess now you're in the state where you are making your own kind of list, but just stop yourself from solving everything, right?
Angela Riggs (08:19):
Yes. And I think the way you put it was, you know, you wanna be useful. I think that's a big motivation for, you know, it's a big driver for me. And so it's sort of hard to put that on hold in the beginning, but you know, you have to. You have to have the context set for yourself. Like, there are reasons the things are the way they are, and if you don't know that historical context, you can actually make things worse by trying to change things.
Lina Zubyte (08:44):
Exactly. That's such a good point, right? That we come with our experience and we don't know the whole history and what people went through. And then we may just actually, yeah, we may lose credibility if we don't understand really well the challenges they're facing. We may even seem cruel in a sense.
Angela Riggs (09:03):
Yes.
Lina Zubyte (09:05):
So talking about your role, what is exactly the team setup you're in? I'm quite curious. So you're a QA manager - how does this actually look like?
Angela Riggs (09:16):
Yes. So our platform team is a mix of software engineers and SDETs. It's about a two-to-one ratio of engineers to SDETs. And so I manage all of the SDETs on the team and I have a co-lead who manages all of the software engineers on the team. And then within that we're actually currently split into two sub-teams, each of their own focused work stream. A lot of times, you know, platform work is a little more sort of kanban style, like you just sort of pick things out of the backlog and go through with them. But right now actually we have a couple of projects that are a little more time-based, uh, with due dates. And so to help sort of, allow the folks to focus better and sort of drive forward to completion, they decided they wanted to try those two sub-teams to help keep things a little more granular and focused.
Lina Zubyte (10:04):
That's really interesting. So you also have like an engineering manager. Is there any kind of overlap with engineering manager and QA manager roles?
Angela Riggs (10:16):
On our team at least? Definitely. We definitely don't view each other as like, Oh, I only think about SDET stuff and you know, Marcin only thinks about engineering stuff. Like we really look at our team as like our team, and like our goal as managers is to have enough knowledge and - shared capability, I guess, that we can support each other's, you know, folks on the team where needed. And also drive forward the vision of the platform team together. So we each have our own set of direct reports and we do all the manager things with them, you know, one-on-ones, career growth, coaching, and things like that. But we also make sure that we each know how the other's direct reports are doing, anything that we can support, things like that. Yeah, it's really good. It's a new setup for me. I haven't ever encountered that before, but it works really well and actually I'm really happy to be a part of it.
Lina Zubyte (11:08):
It sounds really interesting and unusual for me as well, especially now that we are more leading towards enabling developers, programmers to as well think about testing mindset. And partly also it makes sense that you would have very close collaboration with engineering manager because they work so close together, right? So likely the QAs and your team are working very close with the coders.
Angela Riggs (11:35):
Yes. It's nice because I think the way that my - my co-manager's name is Marcin - I think the way that Marcin and I really set the example of collaborating and working together and having that overlap, um, the team does as well. So it's not just, oh, there's dev stuff over here and test stuff over here. But there's really like that understanding of what the other is doing. And you know, if one of the SDETs is checking on a bug and they're in the code base and it's something they can fix - they might go ahead and fix it. And you know, the other engineers take on the verification and QA work depending on capacity. So it's really nice to see.
Lina Zubyte (12:13):
Oh, it is, and I also think it's, it's a very healthy way in a sense. I'm not just taking my own kinda box role, but if I do see, let's say a typo in the code, I can just go ahead and fix it. I don't need to create a Jira ticket for that and then send it to a developer who's maybe working on some other task.
Angela Riggs (12:34):
Yes.
Lina Zubyte (12:36):
So what is your quality strategy then?
Angela Riggs (12:40):
Well, that's a good question. High level, I would say my quality strategy is visibility, reliability, and confidence. And those might not seem like quality things, but I think they're really important aspects of quality teams and quality products. So like, as a platform team, we make things for other engineering teams to use so that they can make things for, you know, our product and our end users. But when you're looking at platform teams and feature teams, timelines and priorities are often not matched up. So we may be working on something that's really important to us that we're rolling out, but if another team is going to adopt it, it probably takes a little bit of work and maybe like updating and changes that aren't a priority for them when compared to the features they're working on. So one of the things that I think is really important is - how can we make it easier for engineering teams to adopt the work that we're doing?
(13:34):
And then a step further, like, how can we make it so that other teams are eager to adopt things we're doing right? And so that's where sort of the visibility comes in. We don't want to be working sort of silently on something for a quarter and then we just introduce it to the other team and go like, Hey, you can use it now. So we want to make sure our work is visible sort of throughout the process so they know it's coming and they can plan, and they can see how it impacts them, like why it's useful for them. And then reliability and confidence kind of go hand in hand. Like, you want to make sure you're building reliable things, you want to make sure there's trust in the things you're building. You want to be able to have not only confidence in the things that we are putting out as a team, but you want other teams to have confidence in the things that we're putting out. And some of that comes to how do we roll those things out, right? So like education, awareness, adoption, like making sure that we're handing things off in a collaborative way and not just like writing the Confluence doc and sending the link to someone to go like, Hey, here you go, go ahead and implement it now. I want to be hands on and really a part of that adoption and not just sort of tossing it over the wall to people.
Lina Zubyte (14:40):
It sounds really nice, but how would you balance it out? How would you balance the engineering excellence and feature work? What if the team says, Oh, I'm too busy, so better to give me this Confluence page and maybe in half a year I'll have time for that?
Angela Riggs (14:56):
Honestly, sometimes that is the solution, right? Like there are - you know, in such a big org especially, and we have within the, you know, within the company we have different orgs, and so there's just gonna be that mismatch sometimes. I think a lot of it comes down to the managers making sure those avenues of communication are open. So like we're talking with each other. So if there are, you know, teams that we know will benefit from the thing that we're building, you know, Marcin and I should be talking with those managers early and often. We can go like, Hey, here's what we're building. Here's why we think you're the right team to sort of proof-of-concept it, you know, what timeline works for you. And it may be like, you know, Please give us the Confluence doc and we'll talk to you in six months. And sometimes that's okay, but it's really just like - where we can, make it easier for them to go like, Okay, we'll start working that in to the work we're doing.
Lina Zubyte (15:49):
Yeah, that sounds really useful. And I think also a good valuable lesson for leadership that we really can shield the teams. I sometimes see the teams take responsibility of decisions and then I realize that, you know, maybe we're not doing a good job as leadership in that sense. If a developer is like, Oh no, I don't know, I don't, I have so much to do, and they feel this enormous pressure and cognitive load. Right? What's your opinion about cognitive load and how would you advise the teams or even leadership to help reduce it?
Angela Riggs (16:27):
Yeah! So I think it's sort of a balance of things, especially on a platform team. You know, we're especially prone to interrupt-driven work, right? We own services that other teams depend on. So as a manager, I can help monitor that and reduce that. So like, one of the things that I've been noticing as I've been onboarding in the past couple months here is that a lot of sort of requests were happening through DMs - you know, direct messages in Slack, and that doesn't scale, right? Like if I'm the one getting DMs, or if one of the engineers or SDETs is getting these requests privately - if that person is out, someone's requests, someone's needs are going unmet and that doesn't reflect well on our team. So we're trying to drive the visibility of those incoming requests. So posting in public channels where folks on the team are able to, you know, once they're in between work, they can go and answer those questions or go help the person who's asking for assistance, instead of those pings that sort of drag your attention out of what you're heads-down on.
(17:29):
It's also one of the things that I'm learning, like as I'm onboarding, is getting comfortable setting boundaries. So if I get, you know, a request for work or an important prioritization from an an external team, it's OK to ask what the level of urgency is. Like, Hey, do I need to have my team stop what they're doing and take a look at this? Can we address it in stand-up tomorrow? Or Hey, can this be addressed in our sprint planning next week? Right? Like, really trying to not just assume - going back to sort of wanting to be useful - not just sort of going like, Oh, let me take care of this right away; but really sort of working with my own boundaries and communicating to the manager. Like asking questions of, How urgent is this? And how can we sort of fit this into what we're doing as well? I think that's a big part of it. And then from the IC level, I think, you know, something that we can do as managers is to encourage a thoughtful planning process. So building the skill of folks to think about like phases of work and incremental work, as well as dependencies and external things that are likely to come up.
Lina Zubyte (18:38):
I really like this idea as well of a little bit of planning and also setting up boundaries. I think it's extremely important. We tend to go to extremes, yes or no. I either do it now or I do it tomorrow, or I don't do it at all. Instead of just saying, Hey, like, what is important to me? What are the priorities right now? And just checking in time-to-time with that. And it's normal that they will change, that things will come up. Context may change and we may need to do some context switching, but we can do it consciously.
Angela Riggs (19:15):
Yes.
Lina Zubyte (19:16):
I'm wondering how could the QA mindset help in teams in general? So you have a mix of QAs and engineers or programmers in the teams. So how are you trying to see the QA mindset? What is your process as well? What kind of tests do you have? Are there any kind of knowledge sharings that you do?
Angela Riggs (19:42):
Yeah, so I think, I love this question and I know you have like a few questions within that. And it made me think - you know, when we say QA mindset, it makes me wonder. I feel like we could have a whole podcast episode on just this question - but what do we mean when we say QA mindset, right? I think we tend to mean growth mindsets, focus on soft skills, like the sort of glue work that we think about.
Lina Zubyte (20:06):
Like the glue work term. It's so nice.
Angela Riggs (20:09):
And so I think that's what we think about a lot - but I wonder, do we do a disservice sometimes by us making that assumption that glue work happens for QA? And do we sort of remove the responsibility of that being a part of engineering work? But so I think, yeah, I think it's glue work. I think it's those sort of soft skills. It's the ability to sort of adapt and that flexibility, and I think that that's important for engineers, SDETs, managers, right? I think everyone benefits from being able to build those skills to some degree, especially more so for managers, I think. So I think really just encouraging that glue work, you know, sort of leading by example. So from an automation point of view you know, we have the SDETS writing functional tests alongside the development work that's getting done.
(21:00):
Developers are doing unit tests, and right now we're, you know, the, the sub-teams within our platform team are pretty deep into, you know, their own feature work. So, you know, we're sort of looking at what we want our coverage to be and why we're thinking about that coverage. And so we do, you know, we have our nightly reporting, the runs take a little bit longer right now. So we have nightly reporting that dumps into a Slack channel for visibility. And we're working on tooling right now, so this is actually is a good question. We're actually in the process of really thinking about our tooling and how we can sort of make testing and the tests that are running more visible so that if we do have failing tests, it's easier to go find out what's failing, find out why it's failing, right?
(21:48):
Is it a flaky test? Was it a code change where the test didn't get updated? Is it a flaky environment issue? You know, there's all sorts of environment things that happen and it's easy if you have, you know, flakiness somewhere within your process to start ignoring what's happening. And so one of the things that the team is working on right now is making it easier to sort of troubleshoot and understand where the gaps in our process are so that we can fix them and make it easier for those processes to help us do better work.
Lina Zubyte (22:19):
Yeah. Strongly believe in reducing the noise that we have. Because the more alerts or some kind of reports they have, sometimes it gets overwhelming and yet again, then we're building the bigger cognitive load, which means that we may be too overwhelmed to do any action. I feel like making the process easier is a very nice way to motivate the team and to build a better quality product. Are there any other tips that you would have on how could we motivate the teams to build better quality products?
Angela Riggs (22:54):
Yeah, so I think, again, I think process goes back to it. I'm a huge advocate for low overhead process, right? Like, what's the sort of minimum amount of shared process that we need in place to do our jobs well without having to think about the processes that we're using. I think high morale is super important. Encouraging, you know, making it easy for people to collaborate and communicate with each other. And I think part of motivation also comes from both managers and the team being really cognizant of identifying and celebrating wins. It's easy to sort of lose track of the small things along the way that you can consider wins or just celebrate at the end when the thing launches or there's a big change. But there are small changes that I think are really important for morale to like really pull out and celebrate and you know, enjoy in some way. And I think that's a big part of it.
Lina Zubyte (23:50):
Yeah, I think celebration is so important and this is all about iterative deployments and the delivery as well, because when we have a big bang release - I faced a few in my career - the team can get so demotivated, especially if it gets postponed because they're waiting for it. They want their work to be live. They don't want it to be just waiting for some new other feature or some other change. And I think it really affects the morale. So getting small pieces out and also celebrating them, I think that's such a healthy way for the team to function.
Angela Riggs (24:29):
Mm-hmm. Definitely.
Lina Zubyte (24:31):
So why do you think sometimes it's really hard for people to adopt to change?
Angela Riggs (24:39):
Ooh. Change is, is hard. Laura Hogan actually has written some blog posts on there that I really love, but essentially like change is an emotional thing. And especially when people don't have control over the change that's happening, it can feel very scary. You know, Laura Hogan has - the blog post I was thinking about is about desk moves and core needs, and she talks about the BICEPS model and bicep stance were belonging, improvement, choice, equity or equality, progress, and significance, right? And everyone has those core needs to some degree. Some have more of one or another, it probably changes for everyone over time. But change threatens those things, right? And you feel a loss of, um, you know, maybe there's an organizational change and you're worried that, you know, under your new manager you're going to have a loss of your career progress that you've been working on. Or there's a reorg and your team is being absorbed into another team, and maybe you feel like who you are as an employee or the work that you're doing won't be as significant or have as much of an impact and that's really important to you.
(25:46):
So I think it's just adds churn and uncertainty, and people just don't like that. And sort of related to that, a lot of times - not a lot of times, but there are times where, when bigger changes are happening, there's sort of a domino effect of smaller changes and then people get change fatigue. And that's a big hit for psychological safety. It's a big hit for morale, and it just makes it really tough. So I think a big part of being an effective manager is change management and people change management.
Lina Zubyte (26:17):
Yeah. I think that's extremely important. And again, the example why good leadership matters a lot. And I really believe that every single person wants to do a good job. It's just sometimes we don't create people a good environment and we don't allow them to be maybe authentic selves as well, which we want. And talking about authentic selves, I know that you're into diversity and inclusion topics, and empowering people in general. Is there anything inspiring that you noticed recently that you think more companies should do to be better in these topics?
Angela Riggs (26:58):
Yeah, so one thing that I think it maybe seems tangential, but I think it relates to a lot, is the internship program that we have at Sonos. As I'm onboarding, one of the things I'm doing is getting really involved in our core internship work group. And the one of the reasons I think it's really important to have a solid intern program is that it creates a really good pipeline of being able to open up to a diverse range of candidates and really bring in people who are entry level. And sort of growing great engineers and SDETs instead of just looking for people who are already in their careers at big companies. And so being able to give appropriate real-world opportunities so that entry level people are equipped to enter the tech field. You know, it's very different going from a bootcamp or a CS degree into the actual office and it's like, Okay, I have all this, I have a head full of knowledge - what do I actually do with it when I'm coming in, you know, nine-to-five and getting paid for it?
(27:58):
And I think especially with an internship program, in order to sort of make it worthwhile, I guess - maybe that's not the right word - is to really focus on conversion. Like, if you're bringing people in for three months at a time, you're doing a ton of leg work as a company to onboard people and get that knowledge transfer and give them effective things to work on. And then if they, you know, leave after three months and they never come back, they're gonna go benefit somewhere else with all of that knowledge and learning that they spent all of their time and effort getting into. So it's a return on our effort as like a team in a company, but it's also a return on the interns' effort, right? Like they've come in, they got their entry level work out of the way - bring them in as an SDET 1 or a Software Engineer 1 so they can continue that learning. And I think that's hugely important. I know especially for Sonos, our internship program is a huge boost for that.
Lina Zubyte (28:55):
That's so important. I feel like we sometimes look just for senior roles and we underestimate the junior roles and the fact that we can grow people and they are so grateful as well. And the new joiners very often are so passionate, so curious, they're wonderful employees. In Doodle recently we hired a QA who used to be a lawyer, for example. And it's so fascinating to me and I learn so much from different perspectives. Or one of the QAs as well that recently joined used to be a technical writer and she's an avid gamer, so the way she uses the product product is so different than I do. She found many bugs which are related when you navigate just with keyboard. And she like got one pro feature using the free product just because she used keyboard. I was fascinated by that. I'm really, really encouraging, I think hiring people who are maybe from completely different field because they will bring new perspectives, especially that's important for the QA.
(30:10):
So our time is running up. So I wanted to wrap up this conversation and ask you: What is the one piece of advice you'd give for building high quality products and teams?
Angela Riggs (30:26):
I love this question. And I think my answer would be, you know, when you're thinking about high quality products and high quality teams, focus on the team. You know, in my ideal world, high quality work that you produce is the result of quality teams with high trust, high morale, explicit support and collaboration with each other, right? Like that psychological safety, that positive culture of inclusion. You can have quality products without that. Right? You know, tech is a huge field, there are so many companies out there. Not everyone focuses on the high quality team part as the sort of driver of the high quality products. But when possible, I would always prefer to work that way, right? Like, focus on the teams first, and the output that you get from that will be high quality products.
Lina Zubyte (31:18):
Wonderful. Thank you so much, Angela. It was lovely talking to you.
Angela Riggs (31:22):
Thanks for having me. This was fantastic.
Lina Zubyte (31:26):
That's it for today's conversation. Thank you so much for listening. Check out the episode notes for any resources mentioned here. And until the next time, do not forget to keep on building and caring about those high quality products and teams. Bye.