Episode #30: Development Series Production

Announcement: Broadcasting from Fairfax, Virginia. You are now listening to the Highlight cast.

Roman Zhelenko: Hello and welcome back to our development lifecycle series. My name is Roman Zhelenko. I’m one of the directors here at Highlight. And our team is excited to be back with a deep dive into the federal development process through three stages. Pre production, development, and post development and maintenance. Alongside with our team members today, we have Thomas Burford, a tech lead for one of our development contracts. And we have Diljit Singh, who is a DevOps SME for another contract. So today, guys, we’re going to talk about what happens after the team gets on the ground. What are some things that we’re looking for, how we’re adjusting to environments, how we’re dealing with change, how we’re getting to know our clients, et cetera. So the first thing is, I guess I’ll start with Tom. How do you start with a new environment? What are some things that you’re looking for? What are some things that you want to learn as soon as you get in there? So as soon as 

Tom Burford: I get in there, I really like to, so I want to, Depends really on what you’re walking into. If you’re looking at, you know, if you’re walking in and you’re trying to look at an existing product or something like that, like an existing solution that you’re innovating on. I think it really comes down to meeting with the user base. First and foremost, right? Your users are going to tell you more than anything else. Right? So even before you get into like, all right, what am I infrastructure changes? What am I? What does my development environment look like? I want to know. Cool. What do my customers think of the existing product, right? Because that’s going to tell me more than anyone else will in the backend. Um, I find that to be the most important part of picking up a new project. 

Roman Zhelenko: Do you prioritize documentation? Do you like look through the Confluence docs? Do you go through, you know, Jira tickets, et cetera? Or do you just go straight to the user group? 

Tom Burford: I like to go straight to the user group. You know, I’ve had experiences in my past where you pick up and you look at, say, you know, documentation or a Jira board or something like that. And what you see. A lot of times, and what I think a lot of people deal with is a disconnect, you know, between what might have been an old development team, you know, or old management or something like that, and the user base itself. So I really like to, you know, start the groundwork right, you know, we work for the user base. So I like to get up front with them and say, all right, what are you seeing today? And then once I have that perspective, that’s when you start to go back and you say, all right, now I’ve seen the front end, what they’re using, what is that? Let me peel that layer back, right? Let me look behind the curtain now. And that’s when you start looking at, all right, What are, like, are any of these problems correct? And it has been zero board, right? What’s my documentation look like? Can I, you know, they’ve talked about some workflows with me. You know, they click this button. They click that button. They do this. They do that. Can I find documentation that references that? And then from there, right, it’s, it’s looking at the actual code. You know what I mean? So how is this code written? And, you know, what, what languages are out there and then from there, it’s really just expanding into, you know, what’s your pipeline look like? Right? Is there an existing pipeline? Because those aren’t always out there. I’ve had ones in the past where it was all manual builds, manual deployments, right? I find that those are kind of secondary to really getting to know your user base.

Roman Zhelenko: That’s actually a very good perspective. I like that. Because I’ve run into the same situation. A lot of the times the documentation is that last afterthought. It’s kind of just a check. We’ve done it. We’ve put something there to say that we’ve, you know, put something there. How about, how about you, DJ? How was your experience with learning a new environment before we get into learning the pipeline?

Diljeet Singh: Oh, yeah, learning a new environment usually always fun. Like, you know, when, when you’re going into the new environment, you know, sometimes there’s different technology stacks that are used and depending on, you know, how. Um, you know, you’ve probably seen like a couple of different architectural decisions that have been designed and, uh, when you really go into it, you knowing what the like what problems you’re trying to solve and seeing what environment you’re being exposed to it, you kind of see, okay, this is how, These problems are being solved with the current environment that you’re working with. Um, I think, you know, working in a new environment is always gives you like a fresh perspective. And, uh, you know, it’s very easy to say looking at something like, Oh, why was this done this way? But a lot of the times that context about why It was done this way or the decisions that were made, uh, whether or not cost is involved or the architecture that was approved at the time, um, or the technologies that are even approved at the time. They can have a big influence on the environment that you kind of. Do get exposed to. So I think in that regard, it does. It’s kind of cool to see, you know, what people work with and how far they came with what they had kind of thing. 

Roman Zhelenko: So do you like to do you like to start with the incumbent team or another group of developers to set up your space? Or do you prefer to do it on your own and figure out? All right, let me do it this way and then adjust when necessary. 

Diljeet Singh: Oh yeah, if you have, uh, if you if you are able to talk to the incumbent team. I do think that they can usually provide a lot of value as to why decisions were made on, and like certain technologies were adopted. And there are a couple of examples I can even just think of off the top of my head without getting too, too specific where, you know, you join the incumbent team is handing off, you know, their, what they’ve built and what they’ve worked on. And, you know, you ask them questions about, Hey, you know, did you guys consider using this particular use case or did you consider using this? And, you know, sometimes it’s about simply adoption, right? They had tried to go a particular direction and, you know, these are the challenges that they face it face. It’s really good to have that kind of warm handoff because you end up preventing yourself from stepping on the same mistakes that they made or, you know, that knowledge transfer that happens. During that handoff is key because you’re able to basically discern these are the challenges that we are also going to face that aren’t really necessarily outlined as we’re onboarding the project. 

Roman Zhelenko: So, do you ask questions directly to the incumbent team say, hey, why was it done this way? Versus that way? Or why? Why are we choosing this technology over say this newer technology? Or do you kind of wait until you have time to analyze the. The systems that are involved, environments, the technology available, cost, et cetera. 

Diljeet Singh: I think you kind of do have to make some assumptions as soon as you join a new environment, right? So hypothetically, if I’m enjoying joining team A, team A, they have a particular problem that they’re there for that they’ve tried to solve. And when they’re giving us their documentation or just doing some handoff, you kind of do formulate in your head a way of that you would typically approach this particular problem and you kind of to try to come to terms with, okay, this is the decision that they made. And they’re doing it because of this and, you know, it might be different than the way you’re thinking of it. And when you do have that difference, those are good opportunities to ask why they did it in a particular direction. Because maybe the particular problem that you’re trying to solve is actually a lot bigger than you realize. And the incumbents is able to provide that. Context as to why this particular environment exists in the way that it does, or it might be something that the incumbent team didn’t even think of to begin with, or it could be the incumbent team didn’t have the resources to be able to accomplish this particular task in the way that you’re kind of approaching it. So it’s really, it’s always really interesting when you’re going into a new environment, but it’s always good to have an open mind because you’re going to be adopting something that somebody else has built. And I think it’s really good to always look at it from their perspective as to why they built it.

Roman Zhelenko: That’s a good point. You don’t want to jump into something before you have a chance to figure it out. I guess, uh, Tom, do you have the same kind of opinion on it? Do you like to, you know, process it first and then come up with suggestions down the line? 

Tom Burford: You’re telling me I have to keep an open mind now? No, it’s my way or the highway. No, I’m totally kidding. I mean, that’s it. 

Roman Zhelenko: That’s another method. If it works, it works, right? 

Tom Burford: No, I, I totally agree with DJ. Um, I think I think it’s very important. So, as you mentioned, you know, going back to the development team, why? So this decision may not necessarily make sense to me, but. I think it’s safe to say there was a logical reason to make it at the time, right? Time constraints, money, something like that. There’s always a factor. So I think going back to the incumbent team and saying, Hey, you know, I want to make this change. Did you consider this previously? It’s always a good idea, especially if you’re new to an environment, right? I think you got to kind of play with training wheels at first a little bit. So you’re not trying to, you’re not breaking things that might have already been fixed at one point or another, right? 

Roman Zhelenko: I definitely like going to the incumbent team first. I’ve seen situations where, you know, people are ready to go to the client, say, hey, we can do it better, we can do it this way, we can do it that way, when it’s already been explored and, you know, failed in certain situations. So I believe building that client’s trust to show like, alright, I can maintain the system, I can make sure everything is still running before even proposing new solutions. What do you guys think about that? Is that a good approach? We’ll start with DJ on that one. I know you might have had some experience in, you know, maintaining systems.

Diljeet Singh: Yeah, I think that’s very key. Especially when you’re talking to the client, right? Like, there is going to be that time, especially when you’re joining that new environment, where you have the incumbents, or if you’re lucky enough to be in this environment, I would say, where you have your incumbents and you have the client. And as you’re learning more and more things from the incumbents about what they’ve built, how things are working and why it’s working that way, it’ll help formulate what the long term goal that your client wants and help you articulate that correctly. Because if you don’t have that background knowledge, a lot of the times you will end up making the same mistakes that the incumbents made, and it will make it a little bit trickier for you to formulate what that long term plan for your client will be.

Roman Zhelenko: I mean, I kind of love that approach as well. What about benchmarking? I guess this one, this one for Tom. So let’s say you get into a new environment, do you benchmark what, what everything is at now, you know, your code coverage, your runtimes, et cetera, to show like, Hey, here’s some things that we can improve and here’s what we’re proposing. Yeah. 

Tom Burford: I mean, I think it. I think, again, it goes back to what state you’re coming into the project, right? So, I find that if you have a stable system, then yeah, I think that’s a great start, right? I mean, if you’ve got a stable system that doesn’t have a lot of issues, and your user base is pretty happy at that point, and you’re just looking to say, alright, we’re here to make it, then yeah, creating that initial benchmark is fantastic, right? That’s your scientific process in a nutshell. Yeah. I find a lot of value in it. 

Roman Zhelenko: First off, that’s a dream project. Stable. Everything’s running. No issues, right? 

Tom Burford: It’s all about your priorities here. I absolutely 

Roman Zhelenko: love that contract, but let’s say it’s a situation where, you know, you’re coming in there and you can see that there’s some things you can improve and now, now it’s determining how to prioritize those things. What are some things or some. You know, aspects of the system that are like the top of the list. You know, you came, you come in there. You’re like, all right, these are the issues. Here’s what I want to prioritize. Here’s what I’m bringing to the client. 

Tom Burford: I think it always, again, I think it always comes back to user satisfaction. Right. So, um, we, if I’m looking at like, you know, uh, yeah, I think it, it comes back to user satisfaction. If a user is, if, if a product’s being used and they’re unhappy at that point, then I think it really comes down to that’s your highest priority, right? Now. That also goes to say your user base doesn’t include people that directly use it. It’s also going to be your security team. If you have any security requirements, so you’re going to want to make sure those that would be that would fall pretty high on my priority list, right? Are we meeting our security goals in general? You know, and then do we have any outside requirements? Do we have any, you know, KPAs that other people are tracking? You know, are we meeting those right? Any external requirements? It’s so varied based on the customer, right? That I think that’s, that’s why I struggle with this question. Cause I’d really handle it differently depending on what the needs are at the time. I 

Roman Zhelenko: agree. I think security should always be, you know, a top priority just because of the type of organizations we support, the systems that are involved. It’s always nice to make sure that things are secure. How about you, DJ? Do you have the same kind of opinion? 

Diljeet Singh: Oh yeah, definitely. When it comes to, like, benchmarking, Benchmarking is so important. It’s good to know the limits of your system and, you know, how it’s going to be tested. Typically, I mean, typically depending on, like, Whether or not you’re on like the public sector or the private sector, you know, you might have a third party that’ll come in occasionally and stress test your applications. It definitely like enlightens whether or not the technology stack that you’ve used to solve your particular problems is the correct one. And I think in living in the world that we do, it’s so powerful to have the different technologies like Kafka, SQS, You know, MSK provides their, their flavor of, um, Kafka. I think Confluent has their own offering of it as well. Um, there’s these different technologies that allow you to do many different things and have different use cases for the problems that they do solve. And I think those particular, like that is a really important indicator of, Hey, how, what is the capacity of that I can handle? If I needed to double my capacity, You know, my next iteration or, you know, over the several next iterations, does this align with like what the mission that our org is really trying to push for? A lot of the times, uh, you know, different technologies can be beneficial to multiple teams too. So that adoption is really important. And I think that being very vocal about what you’re trying to solve and what your problems are is really beneficial across your org because multiple teams can benefit from that same, same design. 

Roman Zhelenko: So those are some big changes. We’re going to talk. 

Tom Burford: I just wanted to highlight. So, you know, you mentioned something I wish I had mentioned in mind. So, you said testing right at the back. What kind of testing is the, you know, if you have an incumbent team, what kind of testing of the incumbents, right? You know, testing place, such a big factor, right? So, as a part of that 1st list of things that you’re looking at. What kind of testing is available? That’s an immediate improvement to any system, right? Can I make any existing changes to their testing? Do they even have testing right now? Right? So that’s an immediate value add regardless. You know, that’s something that I find very important. So I’m glad you mentioned that one. 

Roman Zhelenko: And it’s a, it’s a quick thing to kind of put in there. You don’t have to make a radical change. You can do, you know, these small incremental ones, start building the trust on the client and showing that measurable improvement. So I love that. With the big radical changes, you know, coming back to that. I know it takes time. You guys are both tech leads on your teams. You have to anticipate, you have to prepare for that workload. How long does it take, in your opinion, for you to gauge how much work your team can do, how much they can complete and say a sprint cycle, et cetera, right? You know, I know in the initial bit, even setting up the environment varies from person to person.

So I’ll start with Tom on this one. How long does it take to get up and running? I guess to gauge the work, you know, everybody runs differently. Your time to do this task could be a day versus somebody else could be three days. So estimating it, you know, story point of assignment, like, all of that takes time before you can accurately estimate, say, a large scale migration. Where systems have to go down, et cetera. 

Tom Burford: So, obviously, it’s going to depend on the project, right? But to get into a maybe to get into a steady flow, right? To understand how long it takes us to do the process of it, right? I think that takes, you know, you’re ever improving. I think in that case, right? So, my estimates for tasks are always improving. I still have trouble where sometimes, you know, if we’re talking like points, I’ll point at a 5. It took me 3 days. You know, maybe that’s right. Maybe it wasn’t at a team perspective. I think, um, if you’re coming in fresh with a bunch of new people, I think it takes, you know, a good one to two months, I would say just to get into a flow with the new team. If a new team, right, these are all people that haven’t worked together before. It takes a good amount of time to figure out your flow with. All right, this is how everyone points tickets differently. That’s how everyone estimates, right? This is everyone’s ability is, you know, that takes a lot of time. And even after that point, it wasn’t too much. You’re still looking at constant improvements, right?

Roman Zhelenko: And I think that’s a sign of a good question. That’s a, that’s a sign of good leadership though. It’s that constant improvement, knowing that everybody’s different, knowing that you have to adjust to everybody’s different, is it, is it flavor of development? And I don’t know if there’s got to be a better term than that, but you know, figuring out, all right, this resource does it like this, this resources like this, they’re much slower at setting up pipelines. They’re much slower, you know, this type of development, et cetera. How about you, DJ, do you have the same experience from like the backend side of things or

Diljeet Singh: Yeah, definitely. I think, uh, uh, so the question was more like, how long does it take? Was it more towards like, how long does it take to get teams like, um, completely set up?

Roman Zhelenko: Or I guess to, to know your team and the other questions more about like, at what point do you feel comfortable that you can estimate the time to do a large scale project? You know, if you’re doing something small, you’re adding You know, test coverage, et cetera. That’s not as complex as say a migration or something where everybody’s involved and you, your systems are going to have to go down at what point. In your opinion, would you feel like the team is ready? You know, one month after the project start, two months, et cetera.

Diljeet Singh: Oh yeah, definitely. I think to better answer those questions, I think it’s important to understand like some risks that your team might be facing. So for example, sometimes there’s particular risks where to be able to accomplish something, it’s specifically confined to a particular person because not everybody has access to the same tools or the same permissions that everybody needs to be able to complete that task, right? So that would be like a risk on its own where God forbid somebody is not available. Now you’re completely blocked and are not, not able to move forward. I think it’s important to mitigate those risks early on. I think once you’re able to mitigate those risks, you have, your estimation is definitely going to be a lot more accurate.

Roman Zhelenko: I agree. And speaking of risks, actually going back to Tom, with the transition process, I know in certain situations you’ll have an incumbent team. Sometimes you won’t. At what point would you consider it a good time to hand off? Like let’s say optimal situation, you know, you’re on the ground, you’re working with the incumbent team, they’re passing along the support of the system. At what point would you feel? Comfortably be like, all right, my team is ready to take full ownership of this process system, microservice, et cetera. 

Tom Burford: And I think you battle Royale of knowledge transfer. You put the incumbent team versus the new team and you say, all right, who knows who can explain it to me and what are the differences? And then at the end, you say, all right, now, you know, I think, um, I mean, it’s a gradual change, right? So I think like we talked about, you know, adding testing is one great example, how you can really start to understand does my does my new team understand the existing product, right? So are we writing tests that make sense that test valid business logic? You know, because if we are, if we can start predicting those ourselves, if we can start piecing those out, then I’d say we’re in a pretty comfortable position at that point to say, all right, we can, you know, we can start to take this over more so now. 

Roman Zhelenko: Until a prod issue happens, of course. Right. Right, exactly.

Tom Burford: There you go. I mean, prod issue comes up, right? And then, you know, if you’ve already written tests for a product though, then I think it’s, it’s fair to say that you have a pretty good understanding of what to look for. You know, if you’ve had to test the solution, then when a production issue comes up, you should have a better understanding of where to look first. You know, so you can start to narrow down. All right. You’d like the incumbent team, right? The only difference between incumbent and new team, they know where to look first. You know, we’re all looking at the same place, but they know where to look first. And if you’ve done that, kind of that testing behavior first off, again, that kind of check, I think that you, you’d have a better understanding. You’d feel more comfortable figuring out, all right, where do I look for that production, right? 

Roman Zhelenko: And it’s being patient. I mean, you’re never going to be as quick initially as the incumbent team that’s been supporting it for years. The expectations shouldn’t be that. It’s going to take time to find the issue, understand it. Production is always a panic. Production issues are always a panic, so. It’s nice to take a breath, figure it out and roll through it. If we’re lucky to have the incumbent team still available, it’s awesome. Otherwise the hunt begins. How about you, DJ, have you had experience with, you know, running into a production issue right at the beginning of a contract and then just how, how would you have solved that or how have you solved that?

Diljeet Singh: So, yes, I definitely have experience of being, uh, you know, joining a contract and then having a production issue or several production issues as soon as you’re joining. And, you know, some, some, you know, it’s not uncommon for, especially when things are really obscure to have, you know, many teams on the calls and, you know, for these calls to become 25 plus. people on one call trying to figure out what’s going on. When that typically happens, I think it’s important to look at the isolation, right? So, you know, the reason that all you have multiple environments is so that you can try to replicate, you know, what your application is deployment’s going to look like in a more testable scenario or to have it deployed. So you are able to do something. That’s not impactful to your customers. So first things I would typically start with asking is, you know, is this something that’s existing in the lower environments? Is this something that’s newly introduced? Or is this something that happens frequently? So in our particular example, like I can think of a scenario where this was something that happened once every six months. Or so, and, um, you know, then, then we can basically narrow down the scope. If it happens once every six months, it might not be related to what you’re deploying. It might be related to some other tasks that might be running on some type of interval. Those kinds of little data points can provide huge insights as to what you’re actually looking at, because especially joining a contract, going into production issue, it’s kind of like looking for a needle in a haystack. So you have to. Do your best to try to isolate where the issue is. 

Roman Zhelenko: And just narrow down asking the right questions and being like, all right, it’s not this, it’s not this, it’s not this, et cetera, until you find it. But staying calm is a big one. What about those calls where you do have, you know, those 30, 40 different people on the call? Do you find that beneficial or do you prefer to narrow it down and be like, all right, this team’s not needed, this team’s not needed, we only need these four or five people? 

Diljeet Singh: I think a lot of the times it’s better, more beneficial to have Some, uh, you know, if you need to pull in teams cause you have questions, then that’s, I think appropriate. But I think a lot of the times when you have too many people, sometimes tackling the same problem, you do lose. It’s like one of those examples of like too many chefs in the kitchen. It’s like hard to go down a particular direction if you don’t have like one person driving, you know, and trying to eliminate the possibilities.

Yeah. 

Roman Zhelenko: Yeah. You might have had multiple people trying to eliminate the same possibility. So yeah. Running that before. But no, I like that approach. Tom, any, anything, anything different from your side or 

Tom Burford: we’re talking about big calls. I’m always a fan of small calls to anyone that’s been on a meeting with me. I’m always eager. You know, if it’s a, if we’re starting out, say, like a DSU, right? And you’ve got a bunch of people on the call. They’re all getting reports. And at the end, you know, everyone’s going to start saying, all right, we have this 1 issue we want to talk about, right? I’m always the 1st 1 to be like, all right. Who, who actually knows what we’re talking about here? Who needs to be on the call? All right. Everyone else at out, you know, you’re good to go. I don’t need you to sit in there if you don’t need to be here. Right. I think there’s value as DJ pointed out. Right. So, you know, when you’re trying to troubleshoot a complex issue, there’s going to be a lot of different ways that you can look at the problem. Right. And sometimes having, you know, more people is better, but I think the more people you have, the better understanding of ownership you really need. So if you’ve got 30 to 40 people on a call, you need to understand who owns the problem. Because the worst thing is getting off a call, 30 to 40 people, and then no one doing anything because they thought the other, you know, 29, 39 people had it. Right. So I think the more people you have, the more organization you need with how you’re solving. Um, both have, both have their ups and 

Roman Zhelenko: downs. That’s a very good point. How do you leave, how do you make sure to leave the call to guarantee that, all right, or not even guarantee to make sure that somebody is going to own this problem, somebody who’s got the next steps, you know, et cetera, be like, Are you assigning it or are you waiting for a volunteer or was that a, was that a question or just, uh, for your, your personal kind of, if, if you’re leading the team and it’s your issue, are you assigning who owns it or are you the one that owns it yourself?

Tom Burford: So I think it, if there’s. I think it’s always important at the very end of the call. Right. So whenever we hop on, say that there’s an immediate production, if you’re right and you’re, you’re notified at a given time, I think one, it’s important to understand beforehand, right? This is something again, going back to your, what you should set up if you’re coming onto a contact, um, is understanding, right? Who is the first responder for you? Who is the first responder? They might not be able to solve everything, right? You’re never going to have anyone that can answer all the questions. Um, but who’s my first responder that can take control? Right. They can say, all right, that maybe that’s me. In some cases, maybe that’s someone else, but you have to have that understanding for this system. This person’s the first call that person says, all right, we need to bring on more people. Right. And then that person, whoever that whoever you’ve designated at that point, right? He’s in charge of saying at the end of the meeting. All right. What are our next steps? You know, what are our follow ups? All right. Who’s accomplishing those problems? So, in, in my day to day, you know, that is typically me, right? I’m hopping on a call with my team and I’m saying, all right, the very end, I always ask the question or try to always ask the question. Everyone makes mistakes, but what do we need to follow up on? Have we answered all the questions that we asked as a part of this troubleshooting call? You know, all right, do we have a ticket defined for it? You know, who’s, who’s, who’s assigned to that ticket? Who’s owning this problem now? Right? So then we can know everyone’s very clear on who to follow up with. And then most importantly is sharing that information, right? So you might’ve said it on the call, write it down. You know, writing things down is so important because so easy to misinterpret things, especially when everyone’s virtual. Now, you know, can’t see everyone’s faces in general. So you’re already a little mixed up. So writing it down, putting it in the chat at the end of a call. 100 percent will improve your outcome.

Roman Zhelenko: That’s a very good point because, yeah, sometimes you’re not sure what, what the end of the meeting did or what, what the to do list even looks like at the end of the call. So setting it in the chat just makes it so much easier. All right, so tech stack changes. I don’t know if any of you have been in a situation where you get on a team and suddenly the tech stack shifts from, you know, C sharp to Java. How do you adjust? You know, you guys are both technical leads, and you have a development team, and suddenly the Program you’re supporting shifts languages or shifts pipelines. What are some things that you do to mitigate the risk there? I’ll start with Tom on this one. 

Tom Burford: Let’s see, mitigate the risk. I think, you know, at the end of the day, you’re working off of, hopefully you’re working off a requirement, right? So I’d say if you, if you know that that’s incoming, right? You’ve got, say you’re switching from C sharp to Java or any other language, right? I think it’s important to make sure that you have your requirements defined for that. Because, you know, the language matters up until a certain point transferring between the two. If you have your requirements defined, though, then the transition really should be seamless, right? I have did X in this product. I’m going to do Y in this one. Um, I think second to that, they’re looking at a more technical perspective. I think it’s important to remember that languages have different ways of doing right? So, you know, C sharp has its own has its own way of managing all sorts of things. Right? Java does it differently. And I think it’s going back to like a clean code basis, right? You should write in a way that, you should write in a way that isn’t language specific. You know what I mean? You should take advantage of, you know, language peculiarities as well. But, you should write in a way that doesn’t have to be forced into work. Language, and I think that’s important to consider too, if you’re making that transition, right? Maybe they didn’t have that in mind in the original solution. Maybe in the new solution, that’s something that you can start taking advantage of. Um, that’s a pretty high level overview, I guess, of what I would look at. But it makes sense. 

Roman Zhelenko: I use C and Java as an example because they’re similar enough that the transition for developers isn’t as bad. I know if you’re. So the reason I picked Java and C Sharp was because they’re both object oriented, so the transition from a developer, if they have to, is a little bit easier than say, you know, you’re going from Ruby to Java, you know, completely different, or Python, etc. So, so do you work with the team to help them learn the new technology, or do you just, well, how would you address it with your team if they’re, you know, they’re all C Sharp developers and suddenly they have to, you know, adjust to a Java workspace? How would you address it?

Tom Burford: Tough question. I think obviously you’ve got to get your team trained in a given language. And that’s something that’s something you consider as a risk when you’re making the decision to write. So when you’re if you’re talking about making that decision, you have to build in to the time a lot of saying, all right, I’m gonna have to get all of my developers trained up. And what what does that look like? Right? Maybe you. You know, you can start training or maybe it’s just all right. So me personally, I learned better by doing things, right? You know, if I, if I see a course online, that’s all theoretical. It’s not for me. I gotta, I gotta type on the keyboard, right? I gotta put something out there. So I like having, you know, maybe there’s some small problems that we can tackle first again, going back to, you know, testing is a great example of a way of getting up to speed in a language. You know, we go back to testing again, right? I can write. Tests before I necessarily have all my code written out. So that’s a great way of learning a language as well. Yeah, I Go for it. 

Roman Zhelenko: I was gonna say at the end you’re most programmers They know how to think about the problem the language you can adjust to the language. So, you know How about you, DJ? What’s new? I know, I know, you know, quite a, quite a few different languages. How do you adjust to a new one? 

Diljeet Singh: I think a technology stack across the team, it’s always, it’s definitely always a challenge, right? I would typically, for preferences, when it comes to picking a technology stack, one thing that really, I think, appeals to me is whether or not it’s specific to a particular, uh, Type of operating system, for example, with like some older versions of like. net, it might be where it’s only able to run on a windows machine, but you know, with like, I think more, I think newer versions of. net there, I believe they’re actually able to be run on Ubuntu and you know, that would allow you to use different languages like C sharp. And when it comes to like the adoption of the technologies, I think one thing that really helps is frequent brown bags. Right? So when you know if your team is transitioning to this new technology, right? Like if you have a bunch of Java developers and you’re moving to C sharp, for example. You know, having like a frequent amount of brown bags will help your team pick up the technology a little bit faster and also encourage your team to find, you know, more little nuances that people might not have typically found.

Roman Zhelenko: Agreed. Just making sure that they have the support they need if you have to transition. So, 

Diljeet Singh: yeah, definitely. It 

Roman Zhelenko: goes a long way. Learning best practices is always good. Because, you know, anybody can write code. It’s writing good code that takes the time. So, all right. So our last question today is more on, you know, the management of the team. I know in a lot of situations, when you start a contract, it’s multiple other vendors are also On the team. So, Tom, I’m going to start with you. How do you make sure that, you know, your team is vendor agnostic when it comes to supporting the client, you know, making sure that it’s just one team. And then that’s not, you know, company, a company, B company, C, et cetera,

Tom Burford: man. I mean, it, you know, it’s how much time you spend with a person, right? So, obviously, you know, you have every day you have. Yes, use that. That’s how your team structure. So, I mean, it’s about spending time with everyone and making sure that they understand that you’re working against a common goal, right? So, that, that’s really the big thing, right? So, it’s, it’s defining your goal, defining your vision specifically, right? Um, how you want to accomplish the goal, etc. So long as that you come to a, you want to come to an agreement on that. And so long as you have that in the back of your mind, everyone’s working for this common goal. So contractor doesn’t matter. Everyone’s working for this thing. So that’s the best way. I think to really get everyone on the same page. What’s our problem that we’re looking to solve? Right? And then let’s all focus on that.

Roman Zhelenko: I agree. It’s because it’s the client’s mission success, you know, at the end, it doesn’t matter what vendors supporting it. We’re all just working to the same common goals. DJ, same, same opinion or? 

Diljeet Singh: Yeah, I definitely agree with Tom 100%. 

Roman Zhelenko: It takes time. I mean, you got to build the trust on your team. So even if everybody’s from the same company, that, that takes time. They have to make sure everybody has to know what everybody’s capable of. Everybody knows they can rely on each other. So that’s. That’s part of the process, 

Tom Burford: and it goes back to your what we’re talking about earlier to write, um, you know, about getting how do you how long does it take to get a team set up? Right? How long does it take to feel comfortable? You know, pointing out tasks for estimating tasks. I think it’s important, like, early on, if you’re working with a bunch of different contractors, you level, right? You’re like, what’s everyone’s skill set from the forefront. So then it’s not a question when you start to go into the implementation, right? You understand that going into it. You know, someone’s better at Java than C sharp. Someone’s got a more DevOps focus or something like that, right? You can really, I think having that clarification in the very beginning is really important. Definitely. 

Roman Zhelenko: And you just get to know your team well. You know, the easy thing when everybody’s remote, 

Tom Burford: I think, uh, highlights, you know, we should have a barbecue and bring them.

Roman Zhelenko: All right. So for our last question, that’s more of a wrap up question. This is an opinion. This is just something that you guys have experienced. We’ll go back to your earlier development days when you were, you know, starting out. The question is what’s a valuable tip or an example that a tech lead has done or shown you that motivated you or that improved the way you’re thinking. Or that, you know, the reason you’re doing your tech lead job now, I’ll start with DJ on this one. 

Diljeet Singh: I think, uh, one thing that’s helped me is when somebody runs into a particular problem on my team, I think it’s trying to emphasize the importance of going back to like the fundamentals, right? It’s like, okay, how does this fundamentally work? I understand what you’re trying to do with it, but let’s just go back and let’s say it allows you to like holistically take a step back. And really think about, all right, like, you know, starting from ground zero, let’s go and figure out what the problem is. I think sometimes people will get too caught up with what they’re trying to solve that they end up, you know, they end up getting stuck and, you know, being able to have that. That direction to just take a step back and let’s start from somewhere else and, you know, build our way towards a solution. I think it’s found a lot in terms of like, you know, helping your team overcome like blockers and help you like, you know, just figure out solutions to problems and stuff like that. That’s one approach that me personally has helped a lot is like, you know, let’s, let’s take it back to fundamentals. A lot of the times, especially from work from home, people tend not to do the rubber ducky method because they’re not talking to somebody, right? They’ll just, you know, solo and try to solve a particular problem when sometimes the solution is just, you know, talking it through to somebody and, you know, the solution comes in apparent all of a sudden and it’s readily available.

Roman Zhelenko: Oh, I love the rubber ducky method. Whoever I’m working with at home, you know, I’ll call my wife out as like, Hey, can you ignore me for the next 15 minutes while I talk through this helps all the time. I, uh, 

Diljeet Singh: like two years ago, I went to an arcade and I won a hundred something rubber duckies. I have endless rubber duckies, and they’re all different themes too, so they’re like, I have a Christmas one. I got all those. If anybody needs a rubber ducky, you know who to reach out to. 

Roman Zhelenko: I, I love that he alternates them, you know, just doesn’t wanna commit to one . There’s someone on my 

Tom Burford: currency who actually talked about their, their past loss, but given them actually a rubber duck. You give everyone on the team a rubber duck for that exact reason. Like this is what you talk to when you’re looking through a problem. 

Roman Zhelenko: I think that could be our next swag thing, you know, put a little highlight rubber duck somewhere and we’ll ship them out if it works. And I guess, Tom, same question for you, a tech lead that has done something that was motivational or impactful.

Tom Burford: Let’s see, motivational or impactful, let’s see. Something that you just liked, 

Roman Zhelenko: you know, it was like, man, I like the way they’re doing that. That’s really cool. 

Tom Burford: Definitely. So I have a different, my experience has been a little bit different in software development in general. All right. So I actually haven’t been from a background where I’ve had a lot of like tech leads specifically. But what I did have in the past were, You know, people in my career that I could look to that I saw how they managed the given team and that was, and it was eyeopening for me. So a rep, someone from the past, the previous job, he’d always come into the room, like he was, he’s where I got my meeting influence from, he would go in and he’d be like, look, I don’t like meetings, you know, he’s like, I don’t like them, I don’t think they’re necessary. I don’t think you get anything done in meetings. We’re going to have as little meetings as possible, but when we need them, they’re going to be quick. We’re going to have a problem to solve. We’re going to get done. And I absolutely love that. Yeah. Because I never got to a meeting and said, oh, man, I don’t need to be here, right? I, this isn’t, you know, I’m not a part of this. It’s not worth my time. It was always something we had a problem to solve, you know what I mean? And that was always great. Or, you know, it was, it was team bonding, right? We were just, I’m sure it’s team bonding or something like that. I really appreciated that fact. He also was the one that he showed me the importance of really, again, going back to that ownership. So he’d get on a call and it’d be like, all right, who’s in charge of this? You know what I mean? End of the call. Alright, who’s got, who do I talk to afterwards? You know, it’s in a tech lead role, right? It’s all, you know, a part of its, you know, delegation, right? In any leadership role, delegation. And he, like, emphasized that to a T. It was, you know, he would, it was funny because he’d hop on a call sometimes and he’d like, he’d be like, oh man, I could solve this, and he’d like start clicking around, you know. And sometimes he’d actually get to a solution, but a lot of times he’d be like, Yeah, I don’t know. I got to pass, you know, pass this off to the, to the senior, right? Someone that works with it directly and you get a lot of joy out of that. And he’s like, you know, go back and forth with a senior on a team or something. And it would be like, you know, he’s been in those shoes before. So he knows what the job is. Man, I’d have worked on it recently, right? But he’s done it before. So he can really go down to that level and relate really well. So, uh. Yeah. If we’re just talking about people in the past, I think about him a lot. 

Roman Zhelenko: Sounds like it was impactful. I mean, all of those are signs that somebody that should be in a leadership role, no reason to have a meeting. If you’re not getting anything done, there’s no reason to, you know, extend the time there, et cetera. My experience falls in the same category. You know, I, I came from a development background. My biggest impact was having a tech lead that was always calm, no matter what was on fire. It was more like. All right, let’s process it. Let’s figure it out instead of just panicking and trying everything. It’s more taking a breath, figuring out our, here’s who we’re going to get engaged. Here’s who we’re going to talk to. Here’s the steps we’re going to do to figure it out. So that level of calm was, you know, something I aspired to, because, you know, occasionally we’ll run into something that goes down and you’ll get a weekend call or this error is happening, you know, 

Tom Burford: taking a breath as a fundamental DJ was talking about, right. So it goes back to like, all right, let’s, let’s get back to the fundamental. Let’s take it and think about this from the base level and work our way up. Cause yeah, it’s, it’s really easy on a call, especially in a production call, right, to sit there and start getting scatterbrained because there’s a thousand things going on, but again, it’s returning back to, all right. You know, what’s, what are my roots? What are, what are the things I can look at first? 

Roman Zhelenko: And it’s usually the simplest thing. Hopefully. All right. That’s it for us. Thank you for listening to the Highlight Cast. To keep up to date with Highlight’s news and activities, follow us on LinkedIn and visit our website, HighlightTech. com. Tune in for our next episode. Thank you. And see you on the next one. 

The views and opinions expressed in this episode are those of the hosts and do not necessarily reflect Highlight Technologies and or any agency of the US government.