Software testing and program management share many of the same skills and what helps make a software tester effective can also be applied to the world of Program Management and how to be effective in that role.
To that end, Jon Bach joins Matt Heusser to talk about his entry and involvement in the software testing world and his current involvement in the Program Management space, and how software testers can help and work effectively with Program Management.
References:
- Above the Clouds
- Starlink Technology
- Testopsies: Dissecting Your Testing: James Bach and Michael Bolton
- A Trip to Infinity
- Project, Program, and Product Management Special Interest Group (PMSIG)
Transcript:
Michael Larsen (INTRO):
Hello, and welcome to The Testing Show.
Episode 125.
Program Management
This episode was recorded Saturday, October 1, 2022.
In many ways, Software testing and program management share skills. Software testers often make excellent Program Managers. To that end, Matt Heusser welcomes Jon Bach to the show to talk about his involvement in testing world and his current role as a Program Manager, how software testers can interact effectively with PM, and how to go about getting involved as a PM yourself.
And with that… on with the show.
Matthew Heusser (00:00):
You know, I often say that I’m excited about this podcast and we try to get you the best podcast we possibly can. This week, we’ve got John Bach. John contributed to the book, “How to Reduce the Cost of Software Testing” 11 years ago now, which means I think we were writing it 12 years ago. He wrote a chapter (we had about 24 contributors) and we just did a podcast on that. He’s still working in software development and we just started talking again recently and I thought we’d have him on the show. How’d you get started in testing, John? Tell us about it. Well, and welcome to the show. I’m terrible!
Jon Bach (00:40):
<laugh>. I was gonna say I’m really honored to be a guest, Matt, thank you for having me. I love talking shop, giving meaning to this craft of development. My background, I have actually a bachelor’s degree in journalism from the University of Maine. I don’t know if it’s antithetical to tech, but I didn’t get started in tech ’til five years after graduating with my degree, I took some time off to use my degree, wrote a book about me and my dad, who left when I was very young, left my family but went on to be a famous author. Since I grew up basically without him, my book was, “Here’s who I think he really is, the persona that he doesn’t tell anybody”. And I was upset that he never mentioned his family in his books. So I set off on a book to kind of write that wrong and it changed my life.
(01:38):
The course of writing that book and coincidence being what it is, it led me to a different way of perceiving who my dad was. That book took a year or two to write. I lived off my savings. The book was published in 1993, and it’s called “Above the Clouds” and it’s a whole take on being named after one of his books, “Jonathan Livingston Seagull” and being named Jonathan. So Jon J O N, is my tech name. My writer persona is Jonathan. With a first name like Jonathan, and a last name like Bach, and being named after “Jonathan Living Seagull” by Richard Bach, some people would ask, “Hey, is there a connection between that book and you?” And depending on my mood, I’d say either, “Yes”, or be coy about it. The Tech part didn’t come in until I was working at a Borders bookstore, 1994, in Tacoma. During the Christmas rush, they hired temporary employees and I met one of those employees.
(02:34):
I was full time at Borders, just over I guess minimum wage, I suppose, even after graduating. But I liked it. It was rewarding work and I was around books all day. Anyway, I met this Christmas temporary help guy who ran the computer section. We became friends just hanging out in the break room and talking about books and different things, philosophy. And he eventually left cuz the Christmas rush ended and he got a job doing customer support for a commercial real estate database in Seattle. We kept in touch and he said, “Hey, I could use somebody up here, you can make like double your hourly rate. It’d be fun to work together. That’s a small company, come on up and you’d be really good at this.” And I was like, “Well not really into tech.” And he’s like, “No, it’s all about problem-solving.” I’m like, “Cool.”
(03:23):
So I decided to talk to my brother about it. Of course, my brother, James, is fairly famous in the software testing industry. He’s like, “Yeah, you would be good at this.” And I’m like, “Is this what you do?” And he’s like, “No, I’m in software testing so I find problems.” He worked not far from this commercial real estate database company, 10 or so blocks. So I’d go see him and start to learn about computers and tech and testing and then they go to my job. And I fell in love right away with this notion that the product is already broken in several ways and my job is to figure out how to find where it’s broken and no one’s gonna tell me exactly where. Although customer support, you get an idea, a really good idea of where it’s broken. Testing went hand in hand with customer support. And from there, I just fell more and more in love with this pursuit of the treasure and it was actually a lot like my journalism degree, cuz journalism is the pursuit of truth. It’s asking questions like software testing is asking questions. It’s making a report to important people, the world <laugh>, you know like citizens. It is talking about risk, what bad things could happen and why is that important? That’s journalism. So no wonder I loved it and from 1995 on, I’ve been in testing and love it to this day,
Matthew Heusser (04:54):
1995. Wow, you’ve been… well I mean I started in software 97.
Jon Bach (04:58):
Yeah, so about the same. I think my first… I’ve had a couple of entry-level jobs. And one of my first jobs in testing was testing a set of APIs for a company called ST Labs, where my brother worked. My first manager was a guy named Tom Arnold who is still in tech. In fact, I think he’s the CEO of… I’m drawing a blank on it, but basically, software that helps owners track where their pets are. Anyway, Tom was a great guy and still is. He made me feel like I could be technical, and after that, I parlayed that into just trying to interview for a third-party testing outsourcing company as entry-level. Took a few interviews but I got in at Microsoft as a vendor. I think the company was Volt in Redmond. So my first job as a contractor for Microsoft was just testing the installation of Microsoft Bookshelf.
(05:54):
At that time, the internet was just spooling up as you know, and there was encyclopedias on CD_ROMs and dictionaries and all kinds of things. My job was to test this product called Bookshelf, which is Dictionary, Thesaurus, Encyclopedia, et cetera, and just install it, kind of mindless but obviously look for bugs, look for installation problems. And that’s where I really got to learn on the job and learn about testing and learn about tech and then just one job after another put my head down and learned and did as much as I could to get better and it never got old. This search for bugs, this search for problems that are out there and you’ve gotta learn how to reveal them. You don’t break anything, it’s already broken. Where is it broken and how are you gonna find out and what do you do when you find something?
(06:43):
To me, it’s just a fun treasure hunt. Now the last few years, I’ve flipped into the program manager world, which itself is a lot like testing, cuz instead of finding bugs in a product, as a program manager, you’re finding risks and problems in the project, or multiple projects in flight, as you’re coordinating a program of different software capabilities. That’s fun because all kinds of things could go wrong in a software project as you know. And I like being the guy who knows a lot of what’s going on and who should be involved and who’s got the solution and what do we do next? Simply, like who is doing what by when, is about as simple as I could make program management sound <laugh> to the average person, but it’s all the intricacies in that. That reminds me a lot about what could go wrong.
Matthew Heusser (07:38):
When we were talking before the recording, one thing that you had just mentioned, that program management can be simple, yet so many of the programs we have been involved with in our career… I can’t speak for you, but there’s been a lot of things that are just kind of a mess. There have been projects and people that I’ve been adjacent to or on that I was amazed they ever shipped anything… and a couple that didn’t. Our audience is testers, test managers, people that care about software quality. I always think of it as the program management is putting things in place so that the people can be successful on the execution side. Are there any tips and tricks you’ve learned or keys to effective program management?
Jon Bach (08:26):
I think effective program management for me means being aware and astute of things that could go wrong. Just like that software testing mentality. What could go wrong with this stunt? Or this series of stunts? These projects, these ambitions, these requirements that we collect from product managers? They’re in charge of the vision of the service or features that get released. The project managers may attempt to be more administrivia. Jira tickets. Status of things. Setting up meetings and cadences (although that is part of the program management), but a program manager should be able to work with anybody. Testers, product, project, BIZ-DEV, programmers. We are the connective tissue. The muscles and the bones. We’re that horizontal across silos… and people decry silos. They go, “Oh, silos are bad. There’s too much siloed thinking.” I don’t mind that. It’s normal. Silos give us identity. They give us specialty. They help us focus.
(09:38):
But the drawback, I think, in silos and what everybody warns against is, if that’s all we do is stay in our silo and we don’t poke our head up out of our hole that we’re in, we might risk reinventing something that somebody did in another silo. We could have saved all that work and used their API or used their method or their class or their tool, but we didn’t know about it. So, oh well, we accidentally built one cuz we had a need. Our program manager goes to these meetings and listens to silo one and listens to silo two and listens to silo three and says to silo one, “Hey, hey, stop what you’re doing. Consider silo three’s solution” and silo one, hopefully, will say, “What? They’re doing what? Oh, that’s so cool! Hey, who do we talk to?” And I’m like, “Okay, here’s the guy to talk to.” So successful program management to me is all around servant leadership and awareness of what’s going on so that you save time and money for the business and for the teams.
Matthew Heusser (10:38):
So when I hear “program”, I’m sure these terms mean different things at different companies. Some project managers look more like Scrummasters, some look less. When I hear “program”, I think a relatively large amount of money, a project, we’re gonna fund them one at a time, push people through, assemble the team for this project and when we’re done in nine months or a year, do it again, release people back to this big holding cell, pull the ones we need for the next project. Program would look at a larger group of people as a body and then have multiple projects running simultaneously, around a theme maybe, so we can then do staffing so we can actually move things toward a more predictable model while making a larger investment, while developing things in parallel, which is what I think you mean when you’re talking about those various silos. Teams working in parallel on a larger, more ambitious activity. I would say that a program could be anywhere from 20 people, some of whom are part-time to many, many, many people. That’s what I hear when I hear the word. What does it mean to you?
Jon Bach (11:50):
Very similar. It’s about scale and multiplicity. Parallelism. Let’s say a product owner focuses on their product and even the adjacencies on the product to some degree. Well, let’s say they’re working with the programmers on features and they’re working with designers on user experience and then legal comes to them and they say, “Oh yeah, terms and conditions, they gotta work with legal, great.” What a program manager does, part of my work, is… let’s take one of those adjacencies like legal. Legal is working with a product owner about the terms and conditions and then let’s say legal says to the product owner, “Hey, we also have this other project, will that use the same terms and conditions?” And the product owner will shrug and go, “I don’t know, that’s not my project.” Whereas a program manager will say, “I’m working with that team. Yeah, let me start a thread either on Slack or an email and let me get to where you need to go because they might need to know and maybe it’s related to another product that I’m working on.”
(12:48):
And so if I can save legal the bandwidth and the time when we’re working with two different people, I can and I will, especially if those projects are related. So a product manager/product owner will tend to stay in their lane cuz they have to, they gotta focus, they gotta specialize, they gotta get that out. But a program, it’s like a protocol droid, they can speak 14,000 languages and see connections that need to be revealed and maybe even strengthened to optimize what the business is trying to do so they see the big picture I guess is the easiest way to see it.
Matthew Heusser (13:23):
Yeah, that makes sense. When I was at the insurance company, which was a while ago, we had a program manager and I think she was Medicare, so big insurance company and then Medicare was an ongoing thing where there’d be new requirements that would come in. We’d have to adjust new initiatives to make sure they worked with Medicare and we knew who she was. And at the time I was a line programmer… no, I was a project manager… and I would run into her in the hallway and I’d have projects that touched on Medicare. I had to work with her. How do testers work with a program manager person? Do you work with testers, do they make your job easier? How can…
Jon Bach (14:04):
Oh yeah, they make my job really easy. When I need to know a pattern of something or I need to know the status of something, I can ask product owners and they’ll give me status. I can ask developers and they’ll give me status. Testers will give me the status plus some nuance. They’ll tell me things I didn’t ask for, which is really cool. It’s like the police are interrogating a suspect and the person of interest is saying something and the detective, maybe another detective, is looking for body language and tells. And the tester doesn’t hold secrets. They may not know something yet and they’ll be happy to find out for me. They have a dimension of information that you don’t get from many other people on the project just by virtue of them going deeper into a project’s features and revealing problems. But more to your point, one of my favorite ways to work with testers is where I look at bug report as a program manager, I’m looking for how can an element of this program go wrong?
(15:04):
And one is, there’s a stop ship bug somewhere, and there’s a meeting about it. I’m in the meeting and maybe I’m even taking notes and I’m listening for subtext. And let’s say there’s a P-1 bug and we’re talking about it. As a program manager, my job is to be horizontal and to scale and to be in many silos. So it may trigger a conversation I had with a tester on another project who found a similar bug and now I’ve got maybe a smoking gun, I’ve got a reproducible case, not in one project, but two. Who’s looking at that? Maybe nobody, because very few people are horizontal. A program manager can work with a tester, say, “Hey, I see one bug in this project and another bug on this project. Could they be the same root cause?” And you could have key information as a program manager about another bug in another area and have that tester join the call right there in the moment Testers are more than happy to get on a call and say, “Oh, I’m not crazy.”
(16:04):
“Oh, you’re seeing it too? Okay, we should meet, we should talk.” It’s all about custody of information and information flow. Program managers are the grease between the gears and the glue between the silos. Thinking end-to-end, testers do well to think end-to-end, end-to-end scenarios, start at the beginning, have a very rich traversal, end at a particular point, see what problems you can find. But let’s say you’ve got a bug and it gets assigned to a team and they fix it and they go, “Our piece is done.” But wait, that’s not the extent of the bug. The bug actually involves three or four different teams. But one team may say, “Well, we fixed our piece of it, we’re done.” Well wait… who owns the custody of that end-to-end bug? The bug that affects more than one team? Do you write four different bug reports to four different teams?
(16:53):
Well, you could, but who’s gonna do that? All four teams need to know they have a piece of this. Now that happens naturally but a program manager facilitates that conversation. “Hey, thank you team A for fixing your piece. Okay, team B, where are you?” Team B may say, “We have a piece in this? Isn’t it your virtual machine or your pool that’s actually the origin? And they go, “That’s us. We didn’t realize it was causing that.” So you look for ways to connect the dots and testers are a rich source of information about what the dots are.
Matthew Heusser (17:25):
Yeah, I’ve been thinking about a way to communicate this better. Long-time podcast listeners have probably heard this before, but you think about the testing role and the journalism role of what you’re talking about in this program. There’s this idea of this objective search for truth. Many other roles have different incentives. If you’re a tester, that’s the job. Figure out what the bugs are. I was on a project once and they were angry at me for finding too many bugs, and I said, “Do you want me to just not find them? I can do that. Like no problem, I’ll go check my email or surf the web or whatever. It’s fine.” Everybody said, “No, we really wanna know. It’s doing your job. We appreciate it.” There are other roles where you are punished or other companies maybe where you can be punished for telling the truth. I’ve had someone also tell me, “Never let reality get in the way of your project plan. As a tester, I was just offended by that idea. “If it doesn’t have to work, we can ship it tomorrow.” Getting back to what you’re saying, it seems to me that between your journalism training, and your testing work, and now your approach to program management for looking for and removing organizational risks and blockers, you’ve taken that thematic element and weaved it through your career. Would that be fair?
Jon Bach (18:47):
That’s totally fair. I love the way you said that. You’re looking for risks and organizational pathologies, things that people don’t realize are a pathology. But as a program manager, you tend to see patterns, and testers do this, too, but it’s more localized. Let me give you an example that happened recently. I live on Whidbey Island, north of Seattle. It’s a rural-ish kind of environment. The island is about 40 miles long from north to south. And there’s tourists that come. It’s beautiful. Puget Sound and the sunsets, and there’s some touristy kind of things you can do. Very country vibe. Well, there’s a weekly newspaper that’s only for the islanders, basically, the residents on the island in there is a police blotter. There’s probably two dozen little stories about real 9 1 1 calls. a pig was seen in somebody else’s yard, and they called 9 1 1 cause they didn’t know what else to do.
(19:43):
So it’s funny little stories… and they’re all true. So one of the things was somebody called 9 1 1 because they saw a string of lights in the sky. So UFO, and watching YouTube videos, as everyone does, I guess, but I’m a big fan of like tech and aerospace videos. I saw a video of Starlink, Elon Musk’s network of internet, and when a Starlink deploys in space, it leaves this string of dots and there’s a picture of one, and a video one. I’m like, “Oh cool. I bet that’s what it was. I bet it was Starlink.” If the 9 1 1 dispatcher had known about Starlink, they would say, “Nothing to worry about. It’s Starlink. Here’s what it’s about. The little dots in a line in the sky.” It’s one of those things that, because I’m listening to YouTube, I’m looking at this kind of fun thing to read the 9 1 1 police blotter and I can put things together going, “Ah, I know what that is.”
(20:38):
So it’s those kinds of things. In other words, you could be in a project meeting and hear a rumor about something that gets dismissed, but because you were in another meeting talking about something similar, you now have a way to connect those dots. In other words, a project risk. So you’re in a meeting and you hear legal hasn’t signed off yet. So the team says, “Well we’re stopped.” You’re in another meeting and says, “Legal signed off a week ago” for their project. Now, this could be a coincidence. Are they related or are they not? Due diligence says, “Let me send an email to legal”, saying, “Did you sign off on this project or this project and that project?” Maybe five minutes later you get a Slack message saying, “Oh, yeah, No. Both. They’re both good to go.” So you just helped the team from thinking they were stuck to now you give them intel.
(21:23):
In fact, to me, if we ask you as a program manager, “Hey John, would you be willing to check with legal to see?” Now, the product owner can do it too, but let’s say they’re on PTO or they’re not around. So you’re looking for opportunities to be useful and proactive to help a project as well as expose risks. And when a risk is exposed, you’re also, what I try to do, is say, “How can I help?” That’s kind of the ethos of testing is, “We found a bug.” Be ready for the scrutiny of, “Okay, does it happen all the time? What kind of configs are you seeing it? Can you get it to reproduce? When did it start happening? What other follow-up testing are you gonna do?” So be ready for that scrutiny because it could be a mistake you made in your config or it could be something, the tip of the iceberg, and you found the big smoking gun that customer support is taking calls on at this very moment. They’re fielding maybe 20 calls an hour and you inadvertently just found it. And because you’re a program manager, you hear this from the tester and you hear it from customer support and you connect those dots and whammo, you’ve now got a more efficient organization that maybe just mitigated one risk.
Matthew Heusser (22:30):
That’s great. And it reminds me of… some folks here are familiar with the Agile Conference, which has sort of an interesting history. There was the XP Conference, which was the programmer’s conference and the Agile conference, which is more Scrummy, and the two kind of converged and then Agile took over the universe. Suddenly, now, if you weren’t talking about Agile, you were kind of odd. And now I would argue that most software development just is something more like Scrum and Agile development, to the point that we don’t even talk about it like we used to. And right in there during that inflection point, where it still was a little bit… culty is too strong, but there were very strong opinions that were held as beliefs that Agile development was inherently right and the way of the future. And there were people that felt differently. And tell me if you disagree with that characterization. You ran the “Questioning Agile” stage at the Agile Conference.
Jon Bach (23:30):
That’s right. What was that? 2008, I wanna say. But there was one track to the conference planner’s credit, they wanted a track that was critical of Agile. The original title of talks in that track, it was something like “Against Agile” or something. And I was like, “You don’t have to be contrary, but what about if we just titled it Questioning Agile?” It could be contrary or it could just be naturally inquisitive for those who were like, “I can’t get into the Cult of Agile but I could if I saw value in it in my project, so I’m agnostic.” And so that’s what we did. We had a track called Questioning Agile and it was devoted to tracks that were either critical or just honestly questioning what are we doing here. For example, one track was “What is Agile?” The first five minutes of the talk was an agile brainstorm, like free association.
(24:23):
“When you hear the word Agile, what can you think of? Scrum. Retrospective. Stand-up. Fist of five. Planning poker. And then we came up, I think it was 64, where the proctor of the talk said, “Okay, that’s a lot.” It was on a flip chart. And one of the people asked, “All right, so if I’m doing six of the 64, am I Agile? Or do I have to be doing 60 of the 64 to be Agile? If I’m doing one, am I Agile?” And that was the spirit of the talk. Precisely, what does it mean to be Agile? So we talked about “agile” with a lowercase ‘a’ being rapid, and speedy, and adaptive, and “Agile” with an uppercase ‘A’, which is the more the doctrine and the ceremonies and the procedures. And it was a wonderful track to be the steward of.
Matthew Heusser (25:11):
So I was gonna ask you what you took away from that track, but I think you just covered that.
Jon Bach (25:16):
I became an Agile detractor, because I thought it was ceremony, and for ceremony’s sake, to somebody who saw the intent. Then I started reading Extreme Programming books. Kent Beck, and Schwaber, and Alistair Cockburn, and starting to get a sense of, “What were they trying to do? Like the signatories of the manifesto, what were they trying to do differently? And then I kind of got the Spirit of Agile versus the Cult of Agile. Fine. I mean the word “Cult” comes from “culture”, it’s part of that. It’s a way of working. It’s a belief system that is meant to get people aligned on the same track so that life can be more efficient. <laugh>. So no wonder Agile took off, cuz it resonated with a lot of people, what they were trying to do. I just am alert where it becomes something more, like I was in one meeting and the scrum master said… some people sat down at the conference room table and it was a standup and they go, “Nope, you have to stand.” So no one was allowed to literally sit because apparently that makes you lazy or it makes the meeting more inefficient. So it’s like, “Really, you literally have to stand? okay, well what if someone has a bad knee?” And I know it’s only supposed to last 15 minutes or something, but literally, it was that doctrine. “Nope, everybody has to stand.”
Matthew Heusser (26:37):
Well, what if someone’s in a wheelchair?
Jon Bach (26:39):
<laugh>. That’s right. there’s that.
Matthew Heusser (26:42):
So what I would hope… if it were me, I would say, “Well the purpose of the standing is to make it uncomfortable to stand for more than 15 minutes. The meeting has to be short.” This was back when we would meet in person and nowadays everybody just sits down. We wanna make it start to feel awkward so that we get back to your desks and get back to work. We wanna meet in the hallway.
Jon Bach (27:02):
I got the intent, it’s supposed to be short. When I was in college and the editor of my college daily newspaper, which is pretty ambitious to put out a daily, but we had something we used to call a “slug meeting”. And a slug is the title of the article you’re working on. And a slug meeting is all the reporters, all the student reporters get together in a meeting. It’s 20 minutes. And we say, “Okay, what slug are you working on? Who’s got this story?” They take five minutes at the most and talk about what they were intending to write about. What’s the story, what’s the gossip, what’s the juice? Is it page one? Is it page four? Is it sports entertainment kind of thing. It’s a student athlete who got into trouble for drugs? Oh, okay. So that’s now front page sports, maybe even front page of the paper. So the slug meaning was totally Agile because we would adapt based on context by the reporter saying, “Hey, here’s what I just found out. I’m working on this story, it’s taking this different turn.” So I get it. That’s pretty useful in software development. You wanna react and adapt to new information.
Matthew Heusser (28:02):
So if you reduce program management to its most externally visible component, you get, “Who’s doing what, when are they gonna be done?” If you reduce testing to that, then it looks like, “Follow these directions and tell us what’s wrong” or “I have no idea. They just play with it and report errors, I guess, sort of.” I think we should have a larger discussion, bring more people in and talk about how can we define testing. There’ll be someone that brings a book that quotes Cem Kaner or something, which is great, that testing is a technical investigation to the state of the software under… but “What do testers do?” I think, would be a great follow-up podcast.
Jon Bach (28:46):
You know, I don’t know if you’ve seen my brother’s work on “The Secret Life of Testers” that he’s done with Michael Bolton. That’s awesome. That’s another like “What do testers do?” Almost minute by minute. He’s done breakdowns called the Testopsy, which is wonderful. I just watched a documentary about two hours ago about Infinity on Netflix. It’s worth checking out. Infinity is infinitely small or infinitely huge. It’s infinitely fast and infinitely slow. So it’s got these rich dimensions you can slice and dice. So we could look at testing as infinitely unending or finite. You’re looking for one thing, a bug bounty. You find that repro case or you don’t. And there’s very rich dimensions of perspectives we can take on testing, much like program management. There are program managers that are on one project, but there’s still a lot of moving parts on that project to coordinate and facilitate.
(29:34):
I happen to be at the enterprise level, doing a lot of work for eBay Germany, I mean talk about a lot to coordinate. It’s not just U.S. It’s Germany. It’s the actual country and citizens and German customer. So even though in the U.S. we’re like, “Yep, we tested it, we had a program manager in the U.S. and they made sure we hit all our phase gates and all our adjacencies and dependencies and we shipped.” Now it’s like, “Oh yeah, did you also do that for Germany too?” So even the program manager there needs to be aware of where are we shipping to? Is it the big four? You know, U.S., U.K., Germany, Australia. So there’s a really interesting context even there. And of course if you’re talking about Germany, you’re talking about the E.U. Then you’re talking about E.U. regulation. It’s a fascinating thing. I love it because there’s so much to learn and I love being the guy who knows stuff.
(30:21):
Even though there’s a lot to learn. It’s fun to even be in a meeting and then go to another one. And in that second meeting, you are useful because just 10 minutes ago, in the previous meeting, you learn something that is useful to the people who couldn’t come to the previous meeting. You are effective, you feel smart \, and you feel useful and valuable. Although it could be like, “Hey Jon, find out more for us. Would you be willing to?” And now you’ve got a new to-do item. Still, I love the feeling, like I had as a tester. Had it not been for me doing what I’m doing in the way that I chose to do it, maybe this wouldn’t have been discovered. And that’s a fun feeling. And I recommend, if there are testers listening to the podcast and they’re feeling stuck or they’re feeling in a rut, I really recommend program management as a way to branch out and broaden. And I’m always happy on LinkedIn to get a DM from somebody who’s earnestly wanting to learn about what it’s like to be a PM and start to move in that direction.
Matthew Heusser (31:20):
Well, usually we’d ask you for your last thoughts at this point, but I think you just did it. And then we would ask where people can go to connect with you or to learn more. So apparently, LinkedIn.
Jon Bach (31:32):
LinkedIn is my favorite. And another thing is, let me make a pitch for PMSIG. it’s actually PM dash or hyphen SIG.org. It’s a bimonthly meetup every other month. In fact, every even month it’s a webinar and it’s free. It’s devoted to product, program, or project managers. So those three Ps. I’m the host and I pick a guest. I think my next guest is Curtis Stuehrenberg, who will be speaking a week from Wednesday. So it’s every second Wednesday of every even month, for one hour. We do a webinar and it’s live and people can join and ask questions. But we also put it up on YouTube. I say we, it’s sponsored by my previous company I worked in for most of the two-thousands called Quardev, Quardev.com. I’m still on good terms with them and they sponsor that and I agreed to be their host and just do it for the fun of it. So that’s another way you can learn more about program management. But yeah, happy to be contacted on LinkedIn. I’m on there every day.
Matthew Heusser (32:36):
Sounds great. Thanks boss. Clearly we can talk for hours. We’ll bring you back to the show. Thank you so much for finding time on a Saturday. We don’t have Michael with us this week. He’s out at PNSQC, hopefully recording a couple more so we can keep these coming to you on a regular cadence. So thanks Jon, and we’ll keep talking.
Jon Bach (32:54):
Thanks for having me.
Michael Larsen (OUTRO):
That concludes this episode of The Testing Show. We also want to encourage you, our listeners, to give us a rating and a review on Apple podcasts, Google Podcasts, and we are also available on Spotify. Those ratings and reviews, as well as word of mouth and sharing, help raise the visibility of the show and let more people find us. Also, we want to invite you to come join us on The Testing Show Slack channel, as a way to communicate about the show. Talk to us about what you like and what you’d like to hear, and also to help us shape future shows. Please email us at thetestingshow (at) qualitestgroup (dot) com and we will send you an invite to join group. The Testing Show is produced and edited by Michael Larsen, moderated by Matt Heusser, with frequent contributions from our many featured guests who bring the topics and expertise to make the show happen. Additionally, if you have questions you’d like to see addressed on The Testing Show, or if you would like to be a guest on the podcast, please email us at thetestingshow (at) qualitestgroup (dot) com.
