Episode Transcript
[00:00:00] Speaker A: Hello. Welcome to the Rubber Duck Dev show. I'm Chris.
[00:00:02] Speaker B: And I'm Krusten.
[00:00:04] Speaker A: And today we are going to talk about working as a team, because teamwork makes the dream work. Yeah, I just made that. Mm hmm. Yeah. Yeah, I sure did. But before we get into the fun stuff, how was your week?
[00:00:17] Speaker B: Well, it's been two weeks, so had Thanksgiving to course. That was good.
Long weekend. That was good. This was also the pre launch, I guess you'll call it, for my course. So that started on Black Friday and went through Cyber Monday. And I was looking to get some early adopters, and I got more than like, I had a particular goal in mind. I didn't want to have everyone sign up, but it was like I had a goal of this many, and I exceeded that goal. So I'm like, okay, that's a win. Excellent. So anyone who's watching now, thank you so much for deciding to become part of the course. Become to join the course.
[00:01:03] Speaker A: Hi. English.
[00:01:05] Speaker B: Yes, exactly. And in the next week, maybe I'll start sending out some information with regard to it, because part of becoming an early adopter is that I wanted to get feedback from people as well. So as I'm finalizing working on the course, I may have some decision points I want to make, and having some people to provide feedback with regard to that would be beneficial just to make the course better.
[00:01:30] Speaker A: Cool.
[00:01:31] Speaker B: And the official launch is going to be end of January. Like, January 29 is the projected date now.
Excellent. That's the big thing that happened last week. I don't think everything else kind of paled in comparison to that because there was still a lot more work that I did involved with it that I didn't anticipate, but it was good at the end. So how about you? What do you end up doing?
[00:01:58] Speaker A: Well, I got most of my big projects done that were necessary before our Code Freeze. So that's a bit of a waiter.
[00:02:07] Speaker B: And that freezes by when?
[00:02:09] Speaker A: December 15.
[00:02:10] Speaker B: Oh, well, good grief. Still got two weeks.
[00:02:13] Speaker A: Yes. Well, one of them is going into UAT user acceptance testing, so there's probably going to be a bit of back and forth, but back and forth.
[00:02:22] Speaker B: Yeah.
[00:02:24] Speaker A: I think that we're at a position where I can have all that completely nailed down before Code Freeze, because I was really anticipating just getting it to UAT before the Code Freeze and not actually getting it to release, but I may be able to actually get it released by the Code Freeze, which is really good.
[00:02:45] Speaker B: Okay, cool.
[00:02:46] Speaker A: And then I finally sat down and got my vacation time worked out for the holidays. So I get to be off the entire last two weeks of the year, which is really nice. Something to look forward to.
And we're still busy, busy, though. And I'm back to working on some working with the Rswag to try to get all of our external APIs better documented, straightened out for our integrators. So just lots of things going on keeping me busy, but I'm really looking forward to taking a little break for a while because I've just been slamming for several months now.
But anyway all right, so working as a team, do it, love it, bye. No.
[00:03:48] Speaker B: Some people don't love it.
[00:03:49] Speaker A: Right, yeah.
And that seems to be in the world of software development. Developers more often than not tend to lean towards being loners and preferring I just want to talk to my computer and the occasional stand up is fine, but that's just what I want to do. Right, but typically, unless you're a solo developer doing your own thing by yourself and somehow making a living doing that, which is great, you're going to end up working on a team of some sort.
We work as a team on the show, obviously.
And what I wanted to talk about was, and this is something that I have a great deal of interest in, I really am interested in the psychologies and team dynamics and things like that that go on in interpersonal communications on software development teams. It's really interesting. I'm not trained in it, I just am fascinated by it.
[00:04:59] Speaker B: Well, you have experience too.
[00:05:02] Speaker A: Yeah, I'm not formally trained in it. I'm experientially trained in it, though, by.
[00:05:09] Speaker B: The trials of Fire.
[00:05:10] Speaker A: Right. School of hard knocks.
I wanted to talk a little bit about the different challenges that developers face when working on teams and what benefits it can bring to you. Because if you're one of the people that doesn't really like working on teams but prefers to kind of solo lone wolf it, which is perfectly fine, I'm a bit that way myself, or have been from time to time.
But there are benefits actually to working on teams and having tight teams together. So I wanted to talk about just kind of the challenges and benefits and insights to development teams.
So, first off, kind of the benefits, I think is a good place to start.
I know that you've worked on work teams before.
What kind of benefits do you see from that situation?
[00:06:19] Speaker B: Well, are you talking about strictly with regard to software development or other types of teams?
[00:06:27] Speaker A: Mostly software development or technical teams.
[00:06:32] Speaker B: Okay, well, I'll go more wide and just do general technical and then we can talk a little bit about software development. The advantage to working on a team is basically you got to if the project is too big, if there's too much work to get done for a unit of time, you need more people doing the work. Ergo, you got a team. You have a team.
[00:06:55] Speaker A: Right?
[00:06:56] Speaker B: And the other reason for benefit of is different skill sets. So if you have someone who's really good at front end, let them do the front end. If you have someone who's really good at back end, okay, let them spend time on the back end. If you have designers or people who are really good at setting up infrastructure, you need those different skill sets.
Pick the best person for the job and what they're really good at and what they like to do and put them in that spot. So that's another reason that teams are important, is to get the best talent you can working on particular jobs.
[00:07:36] Speaker A: And I think you kind of mentioned a little bit of a point that I see as a huge value to people on the team, which is if you have a team of people, different people can kind of specialize on the things that they most enjoy doing.
[00:07:55] Speaker B: Not just what you're good at, but exactly, it's also what they enjoy doing. You get to spend more time doing what you enjoy ideally.
[00:08:03] Speaker A: Right? And that has huge psychological benefits, happiness and job fulfillment, job satisfaction.
Those things are important. If you have to be the only person doing the whole full stack thing and you hate doing JavaScript, well, I'm sorry you're going to spend time doing it. But if you're on a team and you've got somebody who loves JavaScript and you don't you like doing the database stuff, well great. Then you can spend more time doing the stuff you like and become really specialized and good at it, like a master of database stuff.
I can fiddle with some JavaScript if I have to, but if there's database questions, I'm the person to come to.
There's a lot of personal benefits to being on a team.
There's also a tremendous amount of business benefits to having tight teams.
Team synergies are incredibly important and incredibly effective. And what I mean by that is the one plus one plus one equals ten scenario.
If you've got somebody who can specialize and really pay attention to one area of the project while somebody else is really paying attention to a different area, you have much more focus and specialization to work through specific problems faster and much more efficiently.
So if I know area A really well and there's a problem with area A, I know exactly what to look at to fix the problem really quickly.
But if there's a problem with area B, I don't know that one so well, I could be dangerous over there, but there's somebody on the team that really knows that one and can fix it much faster than I can.
[00:09:51] Speaker B: You can truly be dangerous. You could do something wrong and break something.
[00:09:54] Speaker A: That's right, yeah, I could destroy production.
Not that any of us have ever done that before, but anyway, that's a different story.
[00:10:07] Speaker B: And it also not just even areas, but even kind of going back to what we're talking about before. If you don't like JavaScript but yet you must write it, but maybe you are one 20th the efficiency of working on it.
That's kind of where you can get that tenfold benefit. If you could bring someone that's really good at the JavaScript, that means you don't spend your time on this.
What for you is time suck. Nightmare takes forever. You keep on your optimized path of where your Ten X capabilities are and someone else uses their ten X capabilities with that. Therefore you get this blowout performance or optimized performance for the whole team.
[00:10:51] Speaker A: Right. So every time that I've been involved in, well, synergized teams, you get massive improvements in efficiency and output and people are much happier typically.
Now there's some flip sides to those coins, so let's talk about those. What are the challenges of working on teams?
So what have been kind of your biggest challenges working on teams?
[00:11:21] Speaker B: Um I haven't experienced it. It's mostly just things that I've anecdotally heard.
But I think some people tend to take undue ownership of something and it's like, hey, this turf is mine, don't tread on it.
There's always something that people don't want to do. I mean, that's some of the things I but I haven't really experienced a lot of that.
Yeah, the biggest downside of teams is that the larger number of people working on a particular area or project, the slower everything goes in general, because you have the communication that weighs everything down. Two people can move faster than 20 people, for example.
[00:12:20] Speaker A: Usually most cases well, for technical work anyway.
[00:12:25] Speaker B: Well, I mean there are some case well, we were talking about ten X benefits, but even that breaks down at some point when you have so many people working in a system.
[00:12:38] Speaker A: Right.
And there are times to throw people at the problem, but there's also times to throw but it's definitely not tools at the problem.
[00:12:48] Speaker B: Yeah, it's definitely not linear. You have diminishing returns as you add more people.
[00:12:52] Speaker A: Right.
And that's one of the challenges too. And one of the reasons that I think that happens, and this is the big challenge that I've really paid attention to because I'm really interested in it over my career is the personality differences.
And we've talked about this a lot of times on the show, not from a point of personality conflict, but from the perspective of different brains learn differently, they process information differently, they produce things differently. So just the fact that you've got five people on a team, all of them are going to think differently about stuff, they're all going to want to learn differently. You may have people that learn by reading, you may have people that learn by doing, you may have people that learn by watching.
And those things can sometimes cause a bit of friction. They can be challenging because you need to come up with a system that deals with those things effectively and that's hard to do sometimes.
And then of course sometimes you will have personality conflicts. People that are just not going to get along, they're just not compatible.
They think just so differently that they can't be effective together.
That's in my experience pretty rare but I have seen it happen before.
[00:14:27] Speaker B: And there's also a situation where a particular individual is just not a good fit for the anything.
[00:14:40] Speaker A: Yeah, I've run into some people like that and thankfully never on any of the teams I've worked on, but I've seen that kind of thing happen where somebody got hired come in and was just so horrible to people that he basically broke the entire team down, which was a shame. But that is a management problem, that's a leadership problem that should have been recognized really early on and fixed. In fact, it probably should have been recognized before that person was on the team at all. But it's an experience thing.
[00:15:21] Speaker B: It's hire slow, fire, fast type thing. I mean, sometimes you do what you can, but ultimately until the rubber meets a road and they're on the team or working for you.
[00:15:35] Speaker A: Yeah, I mean there are people that talk a great game in an interview and then turn into complete garbage when they're hired, but unfortunately that's in my experience that's not typical but does happen.
[00:15:47] Speaker B: Yeah.
[00:15:51] Speaker A: So there are a lot of challenges to working on a team just trying, everybody trying to figure out the systems that they need to work communications efficiently. Communication is a huge problem on teams and like you said earlier, the bigger they get, the more that becomes a problem.
So as the team grows, you have to start thinking about, okay, now I need communication tools and management tools and things to make sure everybody has all the information they need and then you end up needing people whose primary focus is communication on the team.
And what ends up happening if you're not careful is you start building a bureaucracy instead of a team like you were talking about before with the hey, this is my area, don't step in it. That's when you start getting bureaucracies, because you start having people say, well, if you're going to make a change, I need to sign off on it, and then this person needs to sign off on it, and then we're going to spend three months doing round robin paperwork garbage and not actually accomplishing anything because everybody wants to have their finger on it, which is a dangerous thing.
[00:17:16] Speaker B: As you were saying, some of this I'm thinking about, it's also deciding how you will do certain things, how you're going to work with the code, are you going to use linters, how should they be configured, all that kind. It's kind of like living with your family. It's like, yeah, okay, we need to do dishes. Who's going to do the dishes? Where should the dishes be put? If they're dirty, where do they go? If they're clean, where do they go? Do they stay in the dishwasher? Do you put them in there dirty and leave them there? Or do you wash the dishes? You leave the clean dishes in there and you don't take them out.
[00:17:46] Speaker A: Right.
[00:17:47] Speaker B: And each person may do something different. And then the other one, one family member yells at the other friend, what are you doing? Why'd you put it like, I thought we did it this right? So the exact same thing happens with code base.
[00:17:59] Speaker A: Didn't we tell you that you needed to put this in your description like 15 times? You're supposed come on. Yeah, but I don't like doing it that way. That doesn't make any sense to me. I see it as waste. Well, yeah, but we decided as a group that that's what we're going to you have that stuff before you get people that are like, this doesn't make any sense to me, so I'm just not going to do it.
And that's part of the personality thing that you have to work on. And if you go into team leadership, if you, if you become like a team lead or something like that, those kind of positions, those are things you really have to pay close attention to because if you get a personality problem on the team, it can very quickly rip the team apart, like in a matter of weeks. It can rip apart what you've spent years putting together and getting working efficiently.
[00:18:57] Speaker B: So if your team scenario you're describing is this like a bad member of the team or the team leaders? Not so great.
[00:19:05] Speaker A: Well, the root cause is a bad member on the team, but the reason.
[00:19:13] Speaker B: That the management isn't addressing is because.
[00:19:17] Speaker A: The team lead isn't paying attention to that problem and lets it get out of hand.
[00:19:23] Speaker B: Not to do anything.
[00:19:25] Speaker A: Yeah.
And that's a tough problem to get to because you don't ever want to call somebody into a meeting and say, listen, you suck and you need to stop being such a jerk. Right. You can't do that.
[00:19:39] Speaker B: You could use different words and probably do something similar, though.
[00:19:42] Speaker A: Right. But even using nice pretty words, that's not a fun conversation to have to have.
[00:19:48] Speaker B: Agreed.
[00:19:50] Speaker A: So there is a tendency to kind of say, it's not as bad as I think it is. We'll just let it go, it's fine.
[00:20:00] Speaker B: Well, people like to avoid conflict or they want to avoid conflicts.
[00:20:05] Speaker A: Most people.
[00:20:06] Speaker B: True. Right. So there are some people that thrive on it, of course, but others may want to avoid it.
But that causes things to fester potentially.
[00:20:17] Speaker A: Right. But what I've found over my career and I'm like that I don't like conflict at all. I just don't. What I've learned over my career, though, is that if I don't just go ahead and deal with that, then I have 20 conflicts I have to deal with instead of just the one that I could have dealt with a few months ago.
[00:20:39] Speaker B: It's like you just got to say, okay, rip the band Aid off. Let's go.
[00:20:42] Speaker A: Right. And it has never been fun conversations. I haven't had to have drastic conversations, but I have had to have conversations with team members and say, all right, look, we need you to start performing better, performing differently. You're lagging behind here, and the rest of the team is suffering because you're not pulling your weight.
So I've had to have some kind of, I guess, come to Jesus moment kind of conversations with people about, hey, there's there's some reality that you need to check here, because I think you're not thinking right and they aren't fun. But what they did is it always turns out good because every time I've had to do that, the person says, oh, okay.
They're usually not this clear headed about it right off, but I appreciate the feedback. It's helping me grow. If you had ignored this, it would have been doing me a disservice as an employee because you're not helping me to grow. Right? If you don't give me feedback, I can't get better because I don't know I'm doing something wrong.
So that's usually the outcome of that. And then the team's happy, the team gets better, this person gets better, and the rising tide floats all ships type of thing.
So but I would say that even if you're not in a team lead position or a management position, management and leadership are two completely different things. Any member of a team can be a leader if they step up and take ownership of issues within the team and then try to work with the team to get those issues resolved. So it's not just team leads that can step up and say, hey, we need some different performance out of you. It's usually easier for team leads to do that, but in small companies, a lot of times you have to kind of rely on the team as each member of the team to kind of be their own team lead in a way.
So working on teams is challenging. There's a lot of stuff involved in it. I actually really enjoy it because I really enjoy watching the psychological aspects and the interactions and learning about the team synergies and team dynamics and things like.
[00:23:16] Speaker C: That, and understanding people and how they operate and how I can work with.
[00:23:24] Speaker A: Them to get the most out of.
[00:23:25] Speaker C: Them, to help them reach potential and.
[00:23:28] Speaker A: To get the most potential for the team.
[00:23:30] Speaker C: That's really neat to me.
[00:23:34] Speaker A: One of the things that I would highly, highly recommend if you're on a.
[00:23:37] Speaker C: Team that you do and if you haven't done it yet, is the whole team do the Strengths Finder quiz.
Okay, it used to be scripts, but I can't remember what it's under now. Hold on.
[00:24:00] Speaker B: Sorry about that. My dog has no mute button.
[00:24:07] Speaker C: Gallup strengths finder that's actually a fantastic.
[00:24:12] Speaker A: Way to not only learn a lot about yourself, it's a very good introspection.
[00:24:18] Speaker C: Tool, but also if you share the.
[00:24:21] Speaker A: Results with your team and have a discussion as a team, about those things, about each person's results. It helps you find out what everybody's good at and what their strengths are and what they're not as strong at.
[00:24:33] Speaker C: And it helps the team figure out.
[00:24:35] Speaker A: Okay, where should these people slot in so that they're the most effective?
[00:24:42] Speaker C: So I highly, highly recommend investing in that.
[00:24:49] Speaker A: It's a pretty simple test.
[00:24:51] Speaker C: It's kind of like a Myers Briggs type of personality test, but it's a little bit more designed for.
[00:25:05] Speaker A: Business focused.
[00:25:06] Speaker C: Feedback than personal feedback, really.
[00:25:12] Speaker B: Right.
[00:25:15] Speaker A: But yeah, learning about each other, not that you have to be family, but you are work colleagues and so you should kind of know how your colleagues operate and what things you shouldn't say to them and what things make them happy and how to encourage them, that kind of thing, because everybody's different.
And to me, I think that's the biggest challenge of working on a team is the actual psychology. Of course, I think that's the biggest challenge of being a human. But yeah.
[00:25:58] Speaker B: I want this, somebody else wants that. So there you go.
[00:26:04] Speaker A: Anyway.
[00:26:07] Speaker B: Sorry. In terms of teamwork, what's your experience with or what would you like to say with regard to this? With regards to peer programming, how often do you see it in your organization or others that you've worked with and what do you think? I know we've had a whole show about it, but I didn't know if you wanted to speak to that a little bit about with regard to this topic.
[00:26:39] Speaker A: I think that's extraordinarily valuable for building.
[00:26:42] Speaker C: Team synergies because let's say I've got a team of eight people, right, and.
[00:26:49] Speaker A: We work pretty well as a team. We have the team stand ups and.
[00:26:54] Speaker C: We bounce ideas and stuff.
[00:26:57] Speaker A: But what pair programming does is it puts you in a one on one situation with other team members so you can get deeper understandings of how each other think about code and how to communicate more efficiently about code.
And if you start pair programming with every member of the team on and.
[00:27:15] Speaker C: Off, you start developing much better synergies.
[00:27:20] Speaker A: Because you understand how each member of.
[00:27:22] Speaker C: That team thinks and works and how.
[00:27:25] Speaker A: They lay their code out and how they think through problems.
[00:27:28] Speaker C: And that really helps communication efficiency throughout.
[00:27:35] Speaker A: We don't pair program as nearly as much as I'd like to.
[00:27:38] Speaker C: We do it occasionally, but it's not as convenient because I'm a remote worker.
[00:27:46] Speaker A: So setting up times to do pair programming is a little more involved than just walking to the cubicle next door.
[00:27:56] Speaker C: And saying, sitting down and saying, hey, pull this up and help me with it. Right.
[00:28:03] Speaker B: I think some of the tech tools make it easier.
[00:28:07] Speaker A: Yeah, it's more about the scheduling than it is the tooling. The technology of it is a little more weird.
[00:28:19] Speaker B: Now, what do you think about voluntary pair programming? Or involuntary meaning mandated or voluntary?
What are your thoughts with regard to that?
[00:28:31] Speaker A: I don't think mandated pair programming is in any way, shape or form good because if somebody is so averse to pair programming that you have to mandate it, they are not going to get anything out of it.
[00:28:48] Speaker B: In fact and it doesn't have to be that strong term mandating but just making what you were talking about is every person work with every other person you could have as the policy and say I guess you're going toward the mandating it but or are you just voluntarily let people choose to get together if they want?
[00:29:21] Speaker A: Well, I think ultimately that's the best way to do it. But I would say that spending some time, if somebody is resistant to pair programming, having a conversation with them about, well, here's why we like to do this, and just explain to them why and ask them strongly suggest to them that you would like them to give it a shot with whoever is they think is their favorite person on the team.
Give it a shot at least once just to make sure that they don't have misconceptions about what that is.
I don't like peas. Well, try them at least once to see if you actually don't or just don't because it's green. Right, but I think park programming is an extraordinarily good tool for building team synergies as well as it's just really good for efficient coding and knowledge spread.
[00:30:26] Speaker B: Yeah, because you definitely learn a whole lot like you were saying in terms of how someone thinks because otherwise all you're reviewing is PRS that are coming in and you see the result in code but you don't see the thought process as to why they did a particular thing in particular way.
[00:30:43] Speaker A: Right.
[00:30:43] Speaker B: And one of the maybe you hear something in the stand up or something that's the limit of the communication sometimes particularly if you're remote compared to actually pair programming with someone.
[00:30:54] Speaker C: Right.
[00:30:54] Speaker A: And as an example, on the other side of that, when you don't do enough pair programming, this is something we suffer with, that I deal with constantly when I have PRS to review, because we have a policy where anybody who puts a PR up before it can be merged, it has to be reviewed by two other engineers.
[00:31:11] Speaker B: Right.
[00:31:12] Speaker A: And anytime that I'm reviewing something a lot of times I have to go back and say why did you do this? Because I don't understand it. This doesn't make any sense to me. This is not how I would have done it but maybe you have a valid reason. So now we're spending time with back and forth and back and forth on the PRS when if we'd have just sat down and pair programmed we'd have saved all that time. I'd have learned some things, they'd have learned some things.
Right. So there is demonstrably time to be saved by pair programming not to mention all the other benefits of it.
[00:31:56] Speaker B: Yeah. And going back to the mandatory for a minute. My experience in the consulting that I've done, the teams that I've worked with, either they don't do pair programming or it's a voluntary basis. It's kind of like if they have something that they're working on or something they're assigned and they actually want someone to help them out with it or this particular feature, they wanted to work through it. In a pair programming situation, it's up to them to reach out to say, hey, does anybody want to pair with me on this?
[00:32:33] Speaker A: Yeah.
[00:32:33] Speaker B: Is that how it kind of okay. Yeah.
[00:32:36] Speaker A: Most of the time it's, hey, I've run into a problem I can't figure out. I need somebody to come pair with me on this and see if we can knock this out real quick. But it's not just, hey, we've got a new project up. Let's just start it with pair programming. We don't do that. As much as I'd like to, I think pair programming for the sake of pair programming is worthwhile.
[00:32:59] Speaker B: Yeah. My sense is that it's kind of for whatever you're assigned task you're assigned to do, they can then choose to see, hey, does anybody want to pair with me on this? Yeah.
Or if someone has knowledge of a particular area that maybe this is a newer area that they haven't worked in before, then of course it makes even more sense to get someone who has more familiarity with it to join them.
[00:33:28] Speaker A: Right. And I've actually used that as a training tool.
Joe, Susie's been assigned this thing.
You are an expert at that thing. Can you please pair program on her with this? Because I want to spread the knowledge around, and you're going to be the most effective person to teach her this part of the code.
So not that I explain that. I just say, hey, can you pair with her on this?
Because they pretty much know that's why I'm doing this.
And every time I've done that, the person's like, yeah, I'll do that. Because they end up feeling like it makes them feel important. It makes them feel like they're contributing. It makes them feel like they're mentoring somebody and bringing them along.
And who doesn't like to feel like a superhero and and wanted. Right, exactly.
Which is another thing that if you take on team leadership roles, one of the things that you want to be very careful of is you should start lining up to take the crap jobs and leave the good jobs to your teammates, because that's what team leadership is.
It's making sure that the rest of the team is growing and that you're getting all the junk out of the way so they can get better at their jobs, because you've already had a chance to get better at yours, which is why you're in a team leadership position.
And it's not fun doing all the crap jobs, but well, it can be. I actually enjoy looking down. The road and finding the roadblocks and working to get rid of them before the team gets there and has to deal with it.
I actually enjoy doing well.
[00:35:22] Speaker B: It kind of depends on what you mean by the crap jobs or what does that mean to you?
[00:35:28] Speaker A: Well, there are some things I have to do, like, yeah, I'll go set up these tickets before tomorrow morning because they need to be in there as first thing in the morning. And I'm not going to make somebody else work late to do it.
I'll go deal with the customer because the customer is pissed off and wants to talk to somebody, I'll talk to them.
I will run out and get the pizza for the pizza party, not send somebody else to do it.
I will go through and work on this documentation because documentation sucks, but it needs to be done. So I'm not going to make somebody else do it. I'm going to take care of it. Unless somebody likes doing documentation and wants to do it, then I'm like, please do.
[00:36:17] Speaker B: But I actually probably don't do that. I probably take a slightly different act. And I think about as opposed to taking one for the team, I probably normally spread the crap around.
In other words, like, if it documentation, okay, everybody can do it. Or is there I mean, of course I think about things economically and is there someone who I don't know if you have this.
It's different in an offensive environment. There may be someone who is more of an assistant role.
I don't know if you would necessarily have some of these on technical teams, but maybe their expectation is that, hey, getting a pizza is part of the responsibility. Or if that doesn't exist, then I probably go back to spread the crap around. It turns like, hey, this week you get it. Next week you get it next week.
[00:37:15] Speaker A: Yeah, well, and I don't want to try to imply that you should be a doormat for your team.
[00:37:23] Speaker B: Yeah.
[00:37:23] Speaker A: You shouldn't.
[00:37:24] Speaker B: Because I know what you're saying.
[00:37:26] Speaker A: Yeah.
[00:37:26] Speaker B: Because everybody's job is going to suck.
[00:37:28] Speaker A: At some point, right. There's going to be days where, oh, God, this is my job. I don't want to do it, but it's got to get done. I don't care who you are, but you need to have an attitude of, I'm not going to ask that person on the team to do something I wouldn't do for sure. And I should be the first one to do it so that the team sees that I'll do it too.
I'm not just letting shit roll downhill.
[00:37:57] Speaker B: The next time somebody else right.
[00:38:02] Speaker A: And that's why one of the things that I talk to people about, who I'm mentoring about leadership is be the first one in line to sign up for the crap jobs.
Not the only one in line. The first one in line.
[00:38:16] Speaker B: Yeah.
[00:38:17] Speaker A: Right. That's what the leadership is.
And honestly, if you're on a team, just because you're not the team lead or the manager doesn't mean that you can't take a leadership position. And one of the things you can do to do that is be the first one to jump up and say, I'll take this crap job because the team needs it done.
That's how you work yourself into an official team lead position, because everybody then starts looking to you saying, just by de facto, by default, hey, this person's our leader on the team, because they do the things that leaders do.
[00:39:05] Speaker B: Sorry, but I actually wanted to talk about a little bit about team dynamics and how 37 Signals does some things. But did you have something else you wanted to talk about first?
[00:39:15] Speaker A: No, let's go for that.
[00:39:17] Speaker B: So it's interesting how 37 and this is my understanding how 37 Signals does it, and that's my understanding that they actually have, like, two member team. I mean, it's hard to call it a team. I don't know if it's more appropriate to call it a pod or something, but they have a developer and a designer. And so presumably every feature in their apps is developed by one developer, one designer, and they go off and they just do their thing. And if they want to build more features, they just have more of these two person teams. So are you familiar that that's kind of how they do their development work?
[00:39:55] Speaker A: No, I haven't really looked into how they do that.
[00:39:59] Speaker B: Yeah, I find that fascinating. And I wonder, do you have any questions?
Because clearly the programmers are working pretty independently in that scenario. I don't know how they do code reviews, necessarily do like other programmers review and check it in. Yeah, there's a lot of questions. I mean, they talk about it on their podcast, but it's a little bit different than what I've experienced working for.
[00:40:32] Speaker A: Consulting clients and whatnot yeah, I've never experienced that either. Although I am a big fan of cross functional teams.
Usually I'm thinking a little bit bigger than just a designer and a developer, but if that's working for them, great. It's not how I would have thought to do it. But yeah, I mean, cross functional teams are fantastic. I don't for a second think that teams should be just developers.
I don't think those are the optimal teams, really.
You should have a product person involved, you should have a designer involved, and you should have somebody who's at least a liaison to the QA team involved, because all those people are stakeholders in what you're doing. And the closer they are to you doing it, the easier and faster it is to get it.
[00:41:37] Speaker B: I think, you know, calling him a designer, I think they might do a lot of almost all of the front end work. So they're still kind of doing some programming, to my knowledge. But still, it's just one developer. One designer and I think they're kind of responsible. There might be an overarching product person, but I don't think there's a product person for what they're working on. Basically, they have a feature and say, all right, go build this feature. And in terms of QA, it's like, okay, make the feature. The feature doesn't break.
You do your own.
[00:42:11] Speaker A: Yes, but and we do that too.
We have automated tests. One of the requirements for PRS is if it doesn't have a test, it doesn't get approved.
So we have to do our automated tests, but we have to put it up to QA for regression testing and final eyes on the thing. And one of the things we have to do is communicate to the QA department, all right, here's how you test this. And here's what this means. And here's what this feature is. If they're already coming when they get it, they already understand that because they've been kind of involved in development process. QA goes a lot faster.
[00:42:52] Speaker B: Yeah. And I think it's larger organizations that have a department. Yeah, like a lot of my clients, even some of the large SaaS companies, software as a service companies I work with, I don't think they have a QA department.
[00:43:11] Speaker A: No.
Unless you get to be a very large company. Usually don't.
At least in my experience. Most small businesses I've worked with are.
[00:43:23] Speaker B: Well, definitely a small business. I'm talking to even ones with, like, tens of developers. Probably less than 100, I think, still don't have one.
[00:43:35] Speaker A: Yeah, that's very true. We happen to have one. And I have seen some smaller businesses with specialized QA people.
Kind of depends on the product you're making, whether it necessitates that or, um.
[00:43:56] Speaker B: I think it was more mean. Of course I've heard about QA departments. I mean, my wife worked in the QA department for years, but this was before software testing got as good as it is today. Or the tool sets, for sure.
[00:44:12] Speaker A: Yeah. Well, the fact that we don't have to do as much manual testing anymore kind know, has obsoleted some of the need for QA department. Yeah, but there still is some because our QA department as many automated tests as we have, and we have a lot of automated tests, our test suites are huge, and we've got like, a little over 90% test coverage on most of our products. So we have a lot of test coverage, and that's valid coverage, too. It's not just Fluffy number.
Yeah, because I've gone through and made sure that our tests were effective. There's just a lot.
But even then, the QA department still catches things. And a lot of it is usability stuff that developers tend not to think about. I know how this works under the hood. I don't have to think about how intuitive this is, because I already know. Right, but then you give it to somebody and they say, I have no idea.
[00:45:21] Speaker B: Yeah, I guess it's more in tune to you want it to be of quality, not just from bug breaking. Like, hopefully the developer's test takes care of the bug breaking stuff, but it's really is the user experience at the right quality level.
[00:45:42] Speaker A: Right?
[00:45:43] Speaker B: That sounds like what they're doing.
[00:45:45] Speaker A: Right? And that could even be mitigated with the cross functional teams because if you have designers and product people right there, as the development is going, they can say, this isn't going to work, we need to not do it this way. This is confusing the hell out of everybody before it gets to the point of final QA. Whoops. We're going back.
Cross functional teams are far more efficient, typically if they're put together and run well, yeah, but any team can be dysfunctional and it's not helpful. But if they run well, to me, cross functional teams are the most valuable.
[00:46:30] Speaker B: Well, yeah, and that's the whole extreme programming. Get all the stakeholders together and collaborate.
[00:46:41] Speaker A: Anyway.
So yeah, those are our thoughts on teams.
We work as a team, we talk all the time. I misinterpret his texts and show up late to recordings and all kinds of fun stuff.
But what I found on teams, the TLDR, I think here kind of too late for that, but here it is anyway, is that communication, I think, is really the most important part of teamwork and figuring out those communication channels and making them efficient is going to keep the team members the most content happy.
So if you're on a team, start paying attention to the communications and really try to put some effort into making sure those are smooth and that'll smooth out a lot of other things that have wrinkles.
Anyway, hope you guys enjoyed that. Please let us know what you think about teamworks. Do you like working on teams? Do you much prefer the lone wolf type programming? Or do you think maybe you change your mind after this discussion?
We'd like to hear what you have to say, so please drop us some comments below.
Also, please like and subscribe and make sure you hit that notification bell so you know when new episodes come.
We've got another episode coming next week. We haven't talked yet about what topic we're going to have, so I mean, if you've got some topic ideas, throw them in the comments, we'd love to hear them. You can also ping us over on X at Ducky Dev show. We're over there and you can also join our discord and ping us on there. We have a whole channel devoted to topic ideas show topics, so you are more than welcome to come in there and talk. We love talking in there, so all the links to all the things will be in the description below.
So you can come talk to us however you need to talk to us.
So we will see you next week and until then, happy programming.
[00:48:53] Speaker B: Happy programming.
