Ryan Cheley joins me today to talk about some challenges of managing software teams, and how to handle them. We end up talking about a lot of skills that are excellent for software engineers as well as managers.
Some topics discussed:
- handling code reviews
- asking good questions
- being honest about what you can’t do with current resources and data
- discussing tradeoffs and offering solutions that can be completed faster than the ideal solution
- balancing engineering and managing
- making sure documentation happens
- remote teams
- encouraging collaboration
- encouraging non-work-related conversations
- watching out for overworking
Transcript for episode 183 of the Test & Code Podcast
This transcript starts as an auto generated transcript.
PRs welcome if you want to help fix any errors.
00:00:01 [Brian] Ryan Ceely joins me today. Talk about challenges of managing software teams and how to handle them. However, we end up talking about a lot of skills that are excellent for software engineers as well as managers.
00:00:12 [Brian] This episode is sponsored by Rollbar. Rollbar is the leading platform that enables developers to proactively, discover and resolve issues in their code, allowing them to work on continuous code improvement throughout the software development lifecycle. Rollbar has plans for all situations, from free to large enterprise. With Rollbar, developers deploy better software faster and can quickly recover from critical errors as they happen. Learn More at Rollbar.com Thanks, Rollbar.
00:00:55 [Brian] Welcome to Test and Code.
00:01:07 [Brian] Today on Test and Code, I’ve got Ryan Sheley.
00:01:10 [Brian] Is that right? Yeah, that’s right. You got to write to hear about it. Yeah.
00:01:15 [Brian] Welcome to the show. I’m excited to talk about we’re going to talk about managing software teams.
00:01:20 [Ryan] As he said, my name is Ryan Sheila. I work for medical services organization in Southern California called Desert Oasis Healthcare. Desert Oasis Healthcare is part of a larger organization called Heritage Provider Network, which has ten organizations in California, one in Arizona, one in New York, and one in Colorado.
00:01:38 [Ryan] My official title is Regional Director of Business Informatics. And I get to manage teams in both Arizona and California in Southern California.
00:01:47 [Ryan] And I’ve been with the organization for a little more than 13 years now. I started off as a project analyst and moved my way up the organizational ladder, working as an individual contributor on a couple of development teams and then supervisor manager director.
00:02:04 [Ryan] So, yeah, it’s been a lot of fun. I’ve learned a lot of things. I’ve done a lot of things incorrectly so that I can kind of talk about those and help people, maybe not make some of the same mistakes, but I think I’ve done some things pretty well, too.
00:02:19 [Brian] Oh, that’s cool. So what’s your official title? Are you a director?
00:02:22 [Ryan] Yes, regional Director of Business Informatics. And the regional is because I get to hang out with people in Arizona, in our office in Chandler, which is right outside of Phoenix and prepandemic. I used to get to go out and hang out there for a couple of days a month.
00:02:40 [Brian] But now it’s all remote because of a fluke of what, red tape and stuff for a short period of time, maybe six months.
00:02:51 [Brian] Normally my job title is team lead, but there was some change in the ORC Church system and I was officially and all the team leads in my group were officially directors of something for a while, which was neat. Didn’t change my job any, but I’m like, oh, my gosh, I’m Director of Software Engineering, mobile Radio Test. Such a mouthful. But that was my title. Wow.
00:03:19 [Brian] It was fun. And then I think some people, some people that were actual directors where they were directing other supervisors and managers got upset. And now I’m back to team lead. It’s less high pollutant.
00:03:34 [Ryan] But probably more fun, though, more accurate.
00:03:39 [Brian] Maybe you manage not just software people, but you also manage people that manage software people.
00:03:51 [Ryan] Yes.
00:03:52 [Brian] Right.
00:03:52 [Ryan] Yeah, I do.
00:03:55 [Brian] And there’s probably challenges in both of those.
00:03:57 [Ryan] Yeah. I mean, different sets of challenges with managing supervisors that manage people, the types of questions and mentoring that occurs. There isn’t so much about how to do day to day sorts of activities. I’ve got the two supervisors that report to me. One is the web development supervisor, the other one is a report development supervisor. And they tend to ask questions more about how to motivate their team, any sorts of questions about administrative sorts of things like PTO requests and using all of those administrative applications throughout an organization that when you’re an individual contributor, it looks one way, and when you’re a supervisor above, it looks a different way because suddenly you can see a whole bunch of stuff for more than one person. So those are the types of questions that they’ll ask me about administrative things, but they’ll also ask questions about organizational directions and those kinds of things like what is it that we’re trying to move towards? What are the types of projects we should be focusing on?
00:05:03 [Ryan] Some of the best conversations I’ve had have been with the web development supervisor about new technologies that we can try to implement and use. We’re a Microsoft shop, so everything is Microsoft focused. I try to get bits of Python in where I can, and we’re really kind of hoping to get some Django in there at some point. But there’s lots of inertia you have to overcome with implementing new technology stacks in any organization.
00:05:34 [Ryan] But those are fun things.
00:05:38 [Ryan] So I don’t get so much into how am I going to implement a particular class or a particular WebView or whatever. With the web development team, I tend to have more of a hands on in the report development just because that’s where I feel more comfortable technically on the stack that we use. I’ve been writing SQL for ten or 15 years now. So when those types of questions come up about, well, how do I do these types of joins or even code reviews? I love doing code reviews. It’s one of my favorite things. And when I can do it, I do because it’s an opportunity for me to learn from the person writing the sequel. It’s an opportunity for me to keep my skills sharp in terms of like, oh, wow, I didn’t know about that particular function inside of SQL because we just upgraded to SQL Server 2016 or whatever, and there’s new features in there. So like, those are the types of questions and things I guess I focus on for the supervisors.
00:06:35 [Ryan] One of the things that came up, both of these supervisors started off as individual contributors and then were promoted up to being a supervisor.
00:06:44 [Ryan] And that happened for me too. It happened for me ten years ago. And the thing that happened for me was that I got promoted and I kind of turned off all sense of humanity was the feedback I got from my boss. She had said, you know, Ryan, you need to be a person, and then people will be more apt to follow you where you want to take them. And I was like, oh, all right then. And so with these two new supervisors, that was something that I really stressed with them even before they got promoted was, hey, remember, you’re about to embark on an entirely different path. You’re not going to be just an individual contributor. You’ve got things that you need to continue to do. But don’t forget that you’re still a person and that these are people that you’ve worked with for one year, five years, ten years, however long that you’ve been with the organization and they’ve been with the organization.
00:07:36 [Ryan] So don’t forget to maintain that sense of humanity, that sense of I’m a person, you’re a person. We’re both working on a team together towards a common goal. It just so happens that now you’re the person that’s kind of directing where they’re going to go and what they’re going to be working on.
00:07:53 [Brian] Yeah. And there’s difficult stuff, too. I mean, there is the directing what people do or help at least having a hand in that.
00:08:04 [Brian] But there’s also difficulties when somebody that used to be your coworker, now you’re the one that has to say you’re not being productive enough or in a code review, you are too mean to that other person or the corrective stuff is difficult to do.
00:08:26 [Ryan] Yeah.
00:08:31 [Ryan] I don’t know if I’ve just been extremely lucky or that the culture has just been one such that we’ve been really open and honest with our code reviews and really being like, this is never about you the person who wrote the code. This is about the code that was written by you, the person, and they’re two distinct different things. And so I’ve never been in part of a code review where I was like, oh, gosh, that was really mean of them to say.
00:09:02 [Ryan] But it’s because everything is prefaced with we want to make the code as good as possible, and we all want to learn from this experience.
00:09:11 [Ryan] Initially, that was kind of one of the things of just remembering the point of the code review isn’t to talk about whether or not the person who wrote the code is good or bad. The point of the code review is to talk about is the code doing the thing that it needs to do, doing it in the way that it needs to do it and doing it in the most efficient way possible. And maybe it is, maybe it isn’t.
00:09:29 [Ryan] But then that always kind of level set the expectations for the people on the team.
00:09:34 [Ryan] And I know that they don’t necessarily have that caveat or that opening statement so much anymore because everyone kind of understands it. But with the newer team members that have joined like that’s, something that really has to be emphasized is that this isn’t about you. This isn’t about you as a person. This is about the code that was written.
00:09:55 [Brian] That’s an interesting thing to say, that you have to set expectations within the team of what a code review is going to look like, what the tone is. It’s about the code, it’s not about the person. And we’re trying to create a piece of software that all of us are proud of and can maintain. Right.
00:10:14 [Brian] The other thing is, I don’t know, if you guys talk about it, how long should a code review be? Do we expect?
00:10:21 [Brian] Is it something that’s just getting mostly view comments and approved within a day, or is it something that might take a week to nail down how things look?
00:10:33 [Ryan] Yeah, I guess it depends on the scope of the change. Most code reviews tend to be done within a day of the code review having been requested, and they take anywhere from 15 minutes to a half hour because the changes aren’t like these big monolithic changes. It’s hey, we did the small thing, come and check to make sure that the code that I did meets the standards and does the thing that’s supposed to do, run any test suite that might be on it. And we’ve got from a web development perspective, we’ve got three different applications that we support. One is a legacy VB. Net system that has no tests on it. Like, you’re kind of rolling the dice when you make a change as to whether or not something’s going to break in production. And it’s really scary, right? I mean, those are the code reviews that tend to take the longest because you really have to wrap your mind around, like, what is it that just happened?
00:11:27 [Ryan] And we try not to do any new development on that platform and just bug fixes. And it’s basically in maintenance mode.
00:11:35 [Ryan] I did a code review on a report update last week, and it was like an hour and a half to get through, but it was like seven reports and there was a lot of SQL changes that were going on.
00:11:46 [Ryan] And that was intense because of a whole bunch of different reasons. Like, we store almost all of our SQL store procedures in version control system, but the ones that I was working on didn’t happen to be in that version control system. And I had made all these changes, and so I had to basically scaffold up a local Git version on my desktop to be able to show the differences to the developer I was going to review it with. And so that was a bigger challenge there. But coming back to your original question, sorry, sometimes I Ramble.
00:12:21 [Ryan] They take anywhere from 15 minutes up to an hour and a half, just depending on the complexity.
00:12:26 [Brian] Okay. But I guess that’s something to let people know. We kind of expect everybody to if you’re requested to do it, we expect you to look at it within a day.
00:12:42 [Brian] And if you do a major change, a bunch of changes, there’s going to be more comments and there might be a while to get it to, and that’s fine.
00:12:51 [Ryan] Yeah.
00:12:52 [Brian] And like you said, just trying to have that sense within the team that the purpose of this is so that it’s all maintained and we all know what’s going on. Right.
00:13:07 [Ryan] So one of the things that I read, I don’t even remember when it was, but really hit home with me is that code is written once and read tens if not hundreds of times. And so keeping that in the back of your brain when you’re writing code, because our legacy application, every time anyone goes into it, it’s just like trying to charge through quicksand and you think you’ve got it and then you don’t.
00:13:36 [Ryan] But keeping that in mind for all of our newer applications of like, hey, we’re going to be reading this a whole bunch of times. And so that’s a big part of the code review, too, is like, if you can’t understand what you’re reading during the code review, within a couple of days of the change having been made as a code reviewer, just imagine what it’s going to be like in six months when the person who wrote the code doesn’t remember what they did either.
00:13:59 [Ryan] So that’s an important part. And that’s a big feedback cycle that we have. We try to implement as well.
00:14:06 [Brian] And I try to emphasize that as well, especially with test code, because people read it when they’re already stressed out.
00:14:16 [Brian] The reason why you read some test code is because it’s failing and you don’t know why it’s failing and you’re trying to do something else and this test is in your way.
00:14:27 [Brian] So making tests very readable so that people know what you’re checking, why you’re checking it because some people have a tendency sometimes to say, I don’t even know why this test is here. It doesn’t seem to be helping anything. I’ll just comment it and you don’t want that. So not a good thing or just we’ll put a skip marker on it. It’s not commented out. It’s just being skipped anyway. But one line change fixed it.
00:15:02 [Brian] Right.
00:15:03 [Brian] Okay, so code reviews, we talked about that a little bit since you’ve been in a manager of individual contributors and a manager of managers.
00:15:15 [Brian] Other than code reviews and stuff, what are some of the challenges of being of managing software teams and have you overcome this?
00:15:24 [Ryan] Yeah. I mean, one of the big ones is, I guess developers, I think, are some of the most creative people. Right.
00:15:38 [Ryan] The way that the education system is structured, I think is kind of wrong in that respect. Like, there are these super creative sorts of things like writing code, doing math, they get put into these science sorts of categories. And so there’s the College of Liberal Arts where all the historians and the writers go, and there’s the College of Science and Math. And that’s where we call the math people. And we never have that expectation that they’re going to cross paths. But writing software, it’s an inherently creative process. You are given a problem that you then need to solve, right?
00:16:15 [Brian] Yeah.
00:16:16 [Ryan] And so much of that can be difficult for anyone is having a full understanding of what the problem is.
00:16:28 [Ryan] And so one of the things that I think is super important when you’re talking to either the supervisors or managers of software teams or individual contributors of software teams is helping them to understand what problem is it that we’re trying to solve? That’s a question I’ll ask a lot of times, like from a requester, what problem is it that you’re trying to solve? Because a lot of times requesters will come and say, here is the solution that I want you to implement, okay.
00:16:55 [Ryan] And whenever that happens, because we don’t fundamentally understand the problem, we offer up the solution that was given to us. But it doesn’t solve the real problem because the requester doesn’t necessarily know all of the different things that could be done.
00:17:09 [Ryan] They just know about the thing that they want to have fixed.
00:17:14 [Ryan] And so kind of coming back to that the thing of knowing what the problem is. And then anytime you as a software developer or supervisor or whatever, anytime you make a decision about a thing, know why you made that decision, right? So you’re going through, you’re writing some code and the problem you’ve been given is to keep track of the testing results for Coba tests that have been given. I work in healthcare, like that was a big thing for the last couple of years, is trying to keep track of those kinds of things. And a question, you’re trying to track these COVID tests positive or negative, and you go in and all you’re doing is saying is it positive or is it negative? And so it’s a bit right. It’s binary, it’s bullying, yes. No, right. But those aren’t the only two States of a code test. It could be undetermined.
00:18:10 [Ryan] So if I come back to you and say, well, why did you only do the two? You say, well, cause there’s only two possibilities, either positive or you’re not positive. Like, oh, okay, well, you don’t know that there’s a third state. Alright, let me explain to you why there’s a third state. And so that learning process of making sure that people know why they did the thing that they did, but then helping them to understand it. And you can only get to that understanding if you know why they did what they did. There’s nothing more frustrating than ask someone, well, why did you do this? They’re like, I don’t know. Okay.
00:18:38 [Ryan] All right. Well, then let’s try to figure that out so that you can next time know why you made the decision that you made. And that’s a big thing that I really try to emphasize with my team. It’s like you’re not always going to make the right decision. But that’s okay if you know why you made the decision that you made, because then it offers up a learning opportunity for you, for me, for the team, for everybody. And then we get better as a team when we learn from the mistakes that we’ve made. We can only learn from the mistakes that we’ve made if we know why we did them.
00:19:08 [Brian] Yeah. It’s one of the things that I read once code comments and block comment stuff that describe why not what? Because the code shows you what right and the Y often gets lost.
00:19:24 [Brian] Yeah. So I try to get the Y in comments and also in related documents around the code, but sometimes those can get lost and in commit messages, but those also can get lost, especially if people are squashing things like that.
00:19:40 [Ryan] Yeah.
00:19:41 [Brian] But yeah. Interesting.
00:19:43 [Brian] What problem are you trying to solve?
00:19:46 [Brian] Because I write about testing a lot. I often get, well, how do I test this thing? And I ask back, well, if you weren’t writing an automated test, how would you know if it was working or not? I don’t know. Well, then you can’t write an automated test. You have to get past the I don’t know first, and then we can talk about how you can automate that.
00:20:12 [Ryan] That’s a really good point. Yeah.
00:20:18 [Brian] Knowing what problem you’re trying to solve, it’s a good one.
00:20:22 [Brian] So that’s a good question just to ask people. So I need help with something. Well, what are you trying to do? Right.
00:20:29 [Brian] Good place to start.
00:20:30 [Ryan] Yeah. And there’s a woman named Julia Evans. She goes by the handleb Zero RK on Twitter, and she writes some amazing stuff. She’s got some great scenes out there to help explain just really complicated things. But there were two posts that she wrote about how to ask questions and how to answer questions. And that was something that I shared with my team because knowing how to help our requesters, ask better questions of us helps us deliver better solutions. But then also for us to know how to answer questions internally of each other is also important because there’s so much, I think, institutional knowledge that just gets stuck in someone’s head. Right. Like, oh, well, Brian is the guy that does XYZ and Ryan is the guy that does ABC. It’s like, well, that’s awesome. But is it written down anywhere? If someone needed to cover for Brian while he was out, could anyone do it? And that was one thing that when I got onto my current team, it was sorely lacking. There were lots of holes, and it was like, well, but that’s just what so and so does.
00:21:40 [Ryan] Okay, well, let’s write it down so we know how they do it. We know why they do it, because that’s a big reason, too. Why do they do this thing? Because they’ve always done it. Okay, well, what’s the actual business decision imperative for why it’s being done? Because once you understand that, then you can really try to figure out how you can automate stuff, because that’s a big thing that we do that my team doesn’t work because I’ve got report developers, I’ve got web developers, but I’ve also got data and automation developers, and they figure out how to automate stuff that people like. They got to go and push buttons. Well, that seems silly to have someone go and push a button when it could be automated. Because it’s a computer.
00:22:21 [Ryan] Yes.
00:22:25 [Brian] Also, the logic around what was the reasoning for this? What was the problem that we’re trying to solve?
00:22:34 [Brian] It’s important because sometimes those things change and we can go, oh, that situation is no longer here.
00:22:42 [Brian] This was a workaround for this system XYZ. We don’t use that anymore. The system we have now doesn’t have the same problem, so we don’t need to do those steps anymore.
00:22:53 [Ryan] One of the things that I find is super helpful in trying to really make that come home is by storytelling.
00:23:01 [Ryan] Not my current boss, my boss. Before I report to the CFO of my organization, I’m in the finance division. I’m not in the It division, which is maybe a topic for another time. But one of the things that she really impressed upon me was being able to tell stories to help people understand just various aspects of the business, whether it’s technical, health related, finance stuff, whatever. If you can tell stories, then people have a better understanding of why it is that you’re doing what you’re doing. And one of the stories that you hear is, well, if I’m going to Cook a roast, I have to cut off both ends. And then you ask, well, why do you do that? I don’t know. My mom always did it that way. So you call mom and you ask, Mom, Hey, mom, why do we cut off both ends of the roast? She’s like, I don’t know, because my mom did it. So you called Grandma and you asked Grandma, Hey, Grandma, why did you cut off both ends of the roast when you’re going to Cook it? She’s like, oh, because the pan wasn’t big enough for the roast. So I had to make it fit. Okay.
00:24:00 [Brian] I love that.
00:24:01 [Ryan] Okay, so when you ask people, why do you do this thing? And kind of to your point, like when stuff changes, that’s not necessarily always communicated or communicated well enough for everyone to understand what it means for that change to have occurred.
00:24:18 [Ryan] And so knowing why you did it, why are you cutting off the ends of the roast is to get it to fit in the pan. Well, my pan is big enough now. I don’t need to do that anymore. I’m just wasting roast.
00:24:28 [Brian] I love that.
00:24:30 [Brian] That’s a great story. Also, I’m just thinking of, like, side. I should probably write a book on how to be a bad manager, because not that I’m a bad manager, but I always think about these side things.
00:24:44 [Brian] One rule of thumb might be when somebody asks you a question, make sure that your answer is at least a half an hour long.
00:24:52 [Brian] That way they can only ask you at most two questions an hour.
00:24:59 [Ryan] That’s amazing. I’ve seen the email equivalent of that.
00:25:04 [Brian] Yeah. So people will really be careful about asking you questions if they know they’re going to get a story out of it. Right.
00:25:11 [Brian] Or they’ll love it, they’re like, I just need a story today. I’m going to go ask my boss a question.
00:25:15 [Ryan] Right.
00:25:19 [Brian] Anyway.
00:25:20 [Brian] But the storytelling, actually, to be honest, it makes things sink in, because I’ll always remember that and I’ll always remember, oh, the situation has changed. Now we have a bigger pan. We don’t have to do that.
00:25:36 [Brian] And you see this in legacy code all the time. Why are we doing this? I don’t know. I wasn’t the one that wrote it. I’m just maintaining it.
00:25:44 [Brian] Okay, well, who wrote it? I don’t know, because we changed version control systems about five years ago and we lost all of our history. Okay, well, bummer.
00:25:56 [Ryan] Things like that.
00:25:58 [Ryan] There’s a scheduling application we have at work, and there were a couple of fields that were captured. One was deceased date.
00:26:06 [Ryan] So you call someone to do a schedule for an appointment and you find out that they passed. So you want to indicate that so that the membership records can get updated. But one of the questions that was part of that was, Where did they die?
00:26:20 [Ryan] And I thought, well, that’s a weird thing. Why is that important?
00:26:26 [Ryan] And we’re converting this scheduling system to our newer platform because we have to. And as we were going through, the developer was just taking what was there and putting into the new one. And we did, like, a demo. And I said, Why are we asking that question? And he said, well, because it was on the last one. I said, well, but I’m almost sure there’s nowhere for that information to get put in any one of our systems. And that’s going to be kind of awkward to just ask on the phone.
00:26:49 [Brian] Okay.
00:26:50 [Ryan] I’m really sorry to hear that. So and so passed. Can you tell me where they passed?
00:26:53 [Ryan] I don’t know that I would want to answer that. And so we kind of got down into it. And sure enough, it was information that’s essentially being ignored. No one is using it, so there’s no reason to Port it over to the new system. And there’s no documentation as to why it was asked in the first place. It might have just been a nice to know sort of thing that then got institutionalized into the well, we always ask, but no one like the code wasn’t commented. The original person who wrote the code, any of the specifications on the document, it was all gone.
00:27:22 [Ryan] No one knows why the system is built the way that it’s built, because it’s gone through like three transitions in the time that we’ve had it. So there’s just this field like, oh, okay. But getting back to the why do we ask this question?
00:27:34 [Brian] I don’t know, because grandma always cut off both ends of the but also some of that stuff. It’s interesting.
00:27:43 [Brian] You’re talking about keeping the human aspect of becoming a manager, but also with creating software systems. I think it’s worthwhile for even people that are asked to just automate this thing or create this new Web form to ask back. Really? Should we be doing this? Because if my parents passed away or something and you’re contacting me about something, I don’t want to answer. I don’t even know what you mean by where. Do you mean like what city or what room of the house?
00:28:15 [Brian] I don’t know how to answer that. And then also the date.
00:28:20 [Brian] We need to know why? Because somebody might ask, they’re dead. Just deal with it. Right.
00:28:28 [Brian] But I don’t know. Why do we need the date? Maybe so that you can verify that? I don’t know. Yeah, interesting.
00:28:40 [Brian] But now I got to find a tangent.
00:28:45 [Ryan] You’re exactly right, though. The human parts of software development and using that critical thinking of like, well, why do you need to collect this information? In this particular case, it’s like something that’s a little touchy, because it has to do with the passing of someone that you may be close with, but also just asking the question of like, well, okay, why are we collecting this information? What are we going to do with it from this Web form?
00:29:13 [Ryan] How does that impact other parts of the system? And truly, like understanding? But then that gets back to the bigger question, like, what problem are you trying to solve?
00:29:23 [Brian] One of the things I’ve seen that is a little less touchy is software defect. Practicing systems, often one of the common things is, like, right out of the box, whatever system you’re using, it will ask for, there’s a summary field and a larger description, but then you can customize it and a lot of companies or projects or teams will put in a whole bunch of other fields.
00:29:51 [Brian] And I often push back on that of like, if I need to put information in there, I’ll put it in there. And also just to make sure the fields aren’t required. Because if it’s required, you need to make sure that in all situations, people know how to answer that. And sometimes I don’t know is really the right answer. And people don’t like writing that in there. So making a field option probably better, forcing people to say, I don’t know for sure, but one of the things you mentioned was how to ask a question, how to answer questions. One of the things I found, not just as a manager, but also a software developer, is learning where the resources are to find answers anyway, and then knowing the things that I can’t find out on my own to be able to when I’m talking about a problem or somebody’s, we’re in a meeting with lots of people and somebody’s describing what needs to be done to be able to be thinking about all of the things, all the information you need to implement it, and then coming back and being able to ask a question that really needs to be answered right then or soon.
00:31:10 [Brian] Those skills. Actually, I try to emphasize this with everybody. It doesn’t make you look dumb. It actually makes you look smart for sure to be able to ask questions that maybe somebody hasn’t thought about.
00:31:25 [Brian] And while they’re thinking about a solution being necessary, is the right time for them to think about like, okay, you’re asking me to do this thing. We don’t have some of this information. Where are we going to get that information from?
00:31:39 [Ryan] Yeah, that I think is one of the underappreciated parts about a lot of software development, whether it’s a Web form development or Web application or reports, the number of times that people will ask for data that we simply don’t have and there’s no mechanism to collect it. It’s like, well, we can’t write a report that does that because we don’t know any of that information, because it’s not collected, and there’s no way for us to collect it. So we would have to build the way to collect it before we could even begin to think about asking questions of that data in the first place.
00:32:22 [Ryan] That’s a big part of what we do is trying to figure out where does this data live, if it lives anywhere, what’s the source of truth? How do we get that into a spot where we can leverage it to be able to make our Web forms? Because we’ve got lots of different systems internally, either vendor supplied or internally billed, and we need to integrate those systems in ways to help people most effectively do what it is they need to do. Every time I hear that someone has to have not just several different browser tabs open, but several different browsers open, because one application is only supported on Internet Explorer, one application is only supported in Edge, one application is only supported in Chrome.
00:33:01 [Ryan] It makes me crazy because it’s like, well, why can’t we do something about that? And it turns out we usually can just isn’t a matter of having the people to be able to do it.
00:33:10 [Ryan] That’s the other big thing about managing software teams is that once you have an internal software team is that everyone wants to use the people on that software team to solve their particular problem. And it may not be an imperative of the organization that that particular problem is solved in a software driven sort of way. It may just be an Excel solution.
00:33:30 [Ryan] And people don’t necessarily like to hear that answer because using Excel can be harder for them than it would be otherwise.
00:33:40 [Ryan] I had a conversation with a group where they were talking about needing to generate out a report, but there wasn’t anything to collect the data yet. It’s like, well, we’d have to build something. And we went through a solution that was already built inside of our EHR. And the person that said, well, I just don’t really know if this is going to serve our needs.
00:33:57 [Ryan] Ryan, can you and your team build something? And I said, yeah, we can. But something you got to remember is that the solution inside of the EHR you can start using next week if we want to build a solution. I don’t have people to do that for six months.
00:34:10 [Ryan] So if you want to solve the problem right now, like, here is the solution to solve it right now.
00:34:16 [Ryan] But if you want to wait six months and keep doing Xcel, we can totally do that too. And it’s just trying to get people to understand that the software resources, the software development resources, they aren’t infinite.
00:34:27 [Brian] Right.
00:34:28 [Ryan] And there’s always something that someone wants to have done. And there’s already current projects that are being worked on and just trying to move through all of those things. And so that’s a big part of managing the teams as well, is not just managing the teams, but managing organizational expectations about what’s even possible to do given the resource constraints that we have. And you know, one of the great things that has come out of the pandemic is the remote nature of is really showcasing that development teams can be fully remote.
00:35:01 [Ryan] Like, that was a big thing for a long time. Was that like, oh, we don’t have remote people at work and now we’ve all been remote for two years and we’re just as effective, if not more effective as we were two years ago.
00:35:13 [Brian] So were you in cubicles before?
00:35:16 [Ryan] Yeah, no, it was a large office building with high ceilings and low cubicle walls and developers that it was not the best space for developers, quite honestly. But as I said, I work in the finance division. And so it was like software developers, some analysts, and then claims examiners. And so there wasn’t a good space for the software developers to get together necessarily, and talk through problems. Like you would want to turn around and saying to one of your co workers, hey, can you come take a look at this? I’m having a problem with it. You’d have to go into a conference room where it was quieter because it just needed to be quiet in the room for the claims examiners, and that was really hard. But then moving home and implementing screen sharing like Slack or Zoom or any one of a number of different remote video conferencing software, that really helps because suddenly you don’t have to worry about how long ago you are for anyone else in the room because it’s just you and an office at your house.
00:36:25 [Brian] Most likely, and you’re using your keyboard with your set up, all your stuff. We had a similar situation where we had we didn’t have to be quiet for any particular reason, but it was disruptive. So if you start talking with somebody and you’re working on a problem together for an hour, six people in the room or six or eight people are going to hear you and they’re kind of affected by their productivity. So we had these conference rooms that had all screens and computers and keyboards and stuff set up work there, but it’s not your setup, so it’s more difficult to do. And also the angle of the screen, it might be off the side. It’s more difficult.
00:37:14 [Brian] One of the challenges with working remote, though, is to encourage that, encourage people to say, everybody’s working. So if you need some help with something, just ask, say, hey, can you take a look at something? And then just trying to get in the habit of doing that more often because it’s healthy, be able to say, Can I just grab you for 20 minutes and talk you through what I’m going?
00:37:38 [Brian] I’ve got a solution that I think is going okay, but maybe I’m going in the wrong direction. I just like somebody else’s eyes for a minute.
00:37:46 [Ryan] Yeah, I think that is one of the hardest things is trying to encourage that collaborative nature when everyone’s dispersed.
00:37:58 [Ryan] One of the things that my team does every morning is we do agile, like sorts of things. No one seems to be truly agile because everyone says, oh, well, you’re not doing it right, but that’s a whole other thing. And so every morning we have our stand up where we have we do it on Zoom, we’ve all got our cameras on. We all talk through the three questions.
00:38:18 [Ryan] We do a couple of other things, like reviewing all the issues that came through the day before. And so that’s like the report and data development and the web developers have their own stand up that they do where they essentially do a lot of the same things.
00:38:29 [Ryan] But just seeing your coworkers faces every morning, like, is super helpful in terms of them being less afraid to reach out to someone because you saw their friendly face that morning.
00:38:40 [Ryan] You get a better sense of knowing them and tools like Slack or Discord or whatever it is that you happen to have where you can just push a button and then it rings someone on the other side, and then you’re suddenly just talking with them as though you were on the phone without having to have a phone.
00:38:56 [Ryan] That part is super helpful as well, because you can do some screen sharing and write stuff down and do all those things, but really encouraging the team to use those tools and not just for work related things. When you’re physically in an office, you can run into someone in the break room at the water cooler and you have a ten or 15 minutes conversation about sports or the weather or music or whatever, but that’s not there so much in the remote. And so like setting up channels on Slack or discord, it really encouraged that sort of non work related things, I think is super important because that helps to keep people engaged. It helps people to know each other. And I think a difficulty in bringing and managing people in a remote setting is like someone’s brand new. How do you get them to meet everybody on the team? How do you get them to know who everyone on the team is and what they do and what types of questions you can potentially go to them and ask them? And part of that is the onboarding process. But part of that is also just having these open channels of communication where someone can put something in the channel and be like, I need help. And any one of a number of people like, oh, yeah, I can help you with that.
00:40:04 [Brian] Yeah, I think that’s a great idea. And also, I guess utilizing I’d like to utilize a work in progress for requests, too. A lot to say.
00:40:14 [Brian] I just like some feedback on this and then encouraging people to say, if you’re not comfortable just talking through it with a code review, we’ll just do a Zoom call or something and walk through code together.
00:40:28 [Brian] Yeah.
00:40:29 [Brian] Especially if you have a lot of questions of like, why is this doing that? Why are we doing this? What’s going on? Right.
00:40:36 [Brian] But those are challenges. But I definitely think that, man, I feel way more productive being able to just be home.
00:40:43 [Ryan] Plus.
00:40:47 [Brian] Software people are creative. People are so often are, and that’s sort of an ebb and flow kind of thing. I can’t dictate that I’m going to be creative at particular hours of the day. So I think it’s good to be able to be a little bit flexible with time.
00:41:02 [Ryan] Yeah. And I mean, that’s a super important piece of that flexibility. But one thing that I think is also super important is being creative like that you can sit down for 12 hours in a day, and then you wake up and you’re like, I haven’t eaten today. I haven’t gotten out of my chair today. Where did today go? Right. I hope not.
00:41:24 [Ryan] Well, me too. One of the things that I really advocate for my team is like, don’t put in more than 8 hours in a day if you can help it. Right. Don’t put in more than 40 hours in a week if you can help it. If we have a big project we have to get through and there’s a deadline for it. Yeah, we’ll have to work some overtime or whatever, but come in, do everything you can that day due to the best of your ability. But just remember, it’s still going to be here tomorrow. There’s no reason you’re never going to finish all of it. And that’s for both individual contributors and for supervisors, because the supervisors I mean, you kind of talked about it. It’s like, well, you have these competing senses of what is it should be doing, right? Is it the management piece or is it the engineering piece? And it’s like, well, it’s both, but it’s still going to be here tomorrow, so don’t kill yourself today.
00:42:11 [Brian] That was something that I think we talked about before we started recording. But just to bring it up, I’ve been a manager. I lost how many years now, but my official title is Team Lead. And so what that means to my organization is I’m an engineer also, though I do coding and have tax assigned to me as well as leading other people.
00:42:39 [Brian] But it’s also a management role. So I’m doing, like, performance reviews and raises and stuff like that.
00:42:47 [Brian] But at first, the notion, I mean, we had, like, this rule of thumb of, like, you’re supposed to spend about 30% of your time on management and as an engineer. But even at that, I feel like it was frustrating to me that I couldn’t get as much engineering done as I could before I was a manager.
00:43:08 [Brian] And trying to find the balance of really how much time I should be spending on either, I realized I just needed to talk to other people. I needed to talk to other team leads and my manager to say, what are the expectations really?
00:43:21 [Brian] And be okay with them when I’m working on something. Just work on.
00:43:27 [Brian] So that I mentioned that I had some guilt when I’m working on management stuff, like working on somebody’s goals or their review or something. I feel like there’s engineering tasks that are not getting done right now.
00:43:41 [Brian] And then as a reverse, when I’m just working on a coding problem, I’m thinking I should be checking in with Soandso, because maybe they’re stuck on them and just learning to be it was a learning curve for me to be okay with.
00:43:56 [Brian] No, I’ve scheduled my time today. I’m working on this, and right now I’m working on this, and I don’t need to think about those other things right now. Those will come later, but it is difficult. The transition from IC to management is a difficult chain.
00:44:14 [Ryan] Yeah, no, it is.
00:44:17 [Brian] But we could probably talk about all the challenges of managing software teams for a long time. But is there something you’d like to get in that we haven’t gotten to yet?
00:44:29 [Ryan] I mean, we kind of touched on it documentation, like having documentation is important.
00:44:35 [Brian] Is that software documentation or process documentation or what do you mean both?
00:44:42 [Ryan] Knowing my team is all in on the Atlassian products, we’ve got Jira, we’ve got Confluence, and we leverage those as much as we possibly can.
00:44:52 [Ryan] You hear a lot of things about how awful Jira can be. And it’s true. Jira can just be a nightmare to try to work through if it’s not configured properly. The way you fix that is by having someone who can configure properly part of the team that uses it and can see the ways in which it is difficult to use and can fix it more quickly. Otherwise, what you get is someone deciding from on high what the workflow should be. That doesn’t actually work for anyone on the team. But because Jira integrates so tightly with Confluence, which is what we use for our documentation, every single issue that we have that comes through, like part of the issue work is writing documentation, making sure that for the reports in particular, every report needs to have a documentation page on it. Who is the owner of it? What does it do? What problem is it trying to solve? What issues are related to it? Some metadata about like, well, if someone has a question, like a Frequently asked questions, because that’s something that comes up a lot. Right. When you have a report, what is this report even telling me? Well, it’s telling you these things. Okay.
00:45:50 [Ryan] So like building documentation processes, the writing of documentation, getting built into the process where you are delivering code is an important aspect of just everything. Because again, coming back to the code is written once and read a thousand times. Well, not everyone can read the code because not everyone has access to the source code. But what you can give them is a page that tells them, well, what does this web page do? What does this report do? What does this automation process do? Because then that helps answer questions. And when processes do change, you can refer back to either as a developer or a non technical person and say, oh, well, now I understand why this doesn’t work anymore. It was always contingent upon the Koba test having exactly two names. And we added three more Koba tests, and that’s why nothing’s happening, which was a real thing that happened.
00:46:37 [Brian] Yeah. And the more readable your documentation is, the less questions you get over email and for sure, phone calls and stuff.
00:46:45 [Ryan] For sure.
00:46:45 [Brian] Yeah, probably good. Probably every minute you spend writing documentation, it saves like an hour. In the future of question answer for sure.
00:46:59 [Brian] Well, thanks so much for joining us today and talking about management stuff. Yeah.
00:47:05 [Ryan] Thanks for having me.
00:47:06 [Brian] Good luck with everything in the future.
00:47:08 [Ryan] Thanks.
00:47:15 [Brian] Thank you, Ryan. Very interesting talk. Thank you, Rollbar for sponsoring. Rollbar enables developers to proactively, discover and resolve issues in their code so they can work on continuous code improvement throughout the software lifecycle. Learn more at Rollbar.com thank you, Patreon supporters. Join nem at testandcode.com support. All of those links are in the show notes at testandcode.com. That’s all for now. Now go out and test something.