How to Building High-Performing Engineering Teams with Andrew Duncan

Get ready to discover some of the most actionable DevOps techniques and tooling, including performance and reliability for some of the world's smartest engineers. Hey, I'm Joe Colantonio, host of the DevOps Toolchain podcast and my goal is to help you create DevOps toolchain awesomeness. Hey, it's Joe. And welcome to another episode of the test skill DevOps toolchain. And today we've talked with Andrew Duckman all about how to build high performing engineering teams and more. If you don't know, Andrew is the founder of Veritas Labs, a boutique software engineering firm. Andrew is a highly driven technology executive with a combination of both strategic insights, business expertise, financial skills, and even better, a deep technical experience with a record of success in a bunch of different places with the leadership of basically around application development, vendor management consulting initiatives for major companies and high growth startups. So his company focuses on providing custom software delivery and strategic technical advisory services for small and mid sized companies and startups looking to launch or enhance product and services or increase the efficiency of the technical teams. If you want to learn how to scale up your team, how to make your team more high performing, or anything around that, you don't want to miss this episode, check it out. Are you ready to level up your DevOps game and crush those quality challenges? Whether you're dealing with flaky tests, scaling automation, or trying to integrate security into your pipelines, we got something just for you. Introducing the DevOps Quality Testing Playbook from Test Guild. It isn't just another PDF, it's your go to guide, packed with actual insights, best practices and strategies to help you create a bulletproof DevOps toolchain. It's built specifically for engineers, testers and DevOps teams want to optimize their workflow and drive continuous quality throughout their pipelines. The best part, it's free and ready to download. So don't miss it. Head on over to test Guild Me DevOpsbook and grab your copy today. Stay ahead of the game, optimize your pipelines, and let's crush those quality challenges together. Hey Andrew, welcome to the Guild.

Hey Joe, thanks for having me on.

Great to have you. I guess. Before we get into it, is there anything in your bio that I missed that you want the Guild to know more about?

No, I think you hit the nail on the head. You know, I enjoy helping companies build software, build high performing teams, and so that's why I founded Vertis Labs, to sort of get in the market and to be able to provide that Especially to startups who, you know, they often are faced with the question, do I hire consulting, Do I hire a team? When I hire a team, what do I do? What tech stack do I choose? So that's what I enjoy.

So how did you get into it? Like how did you get into this space then?

Oh yeah, great question. So I always like to start this story with when I was six years old, my grandfather taught me how to build a computer. And when I was 14, I built an e commerce website. And so I've always sort of had this passion to tinker and to build. And so then I went to college, got my degree, started my career and climbed the ranks. And then, you know, ultimately I knew my long term goal was to, you know, own a business and start a company. And so I use the skills that I've gained throughout my career now to provide that as a service to the market.

All right, so obviously you're smart guy, you did a lot of research why this particular niche then on high performance teams? Do you see that this is something companies you were working in were struggling with or when you were doing discovery calls, you found out, oh boy, this is a big area that's not being addressed.

Yeah, great question. So actually, you know, I, early on in my career I worked at companies, we were all, you know, trying to figure out the agile thing and how to build high quality software at speed and to have some predictability around planning the software development process. And so, you know, I spent a lot of time, you know, reading, learning, talking and writing about this topic and then, you know, experimenting with what I found that works, some things that I learned that didn't work along the way. And so, and I'm a people person, right, And I say the hardest part about software is not building the software, it's the people problems that come along with it. And so I spent a large part of my career learning how to build high performing teams. And primarily because one of my biggest peeves is building things that people don't use. And so building a journey of building the things that people do use should be a fun or, and if not fun, at least a rewarding journey. And so by building high performing teams, teams that gel well, that work well, they sort of reach this flow state, we ultimately can produce that outcome of some software product that a company, a client will use faster and in a more enjoyable experience.

All right, so what are some signs then that you have or have not a high performing team?

Oh yeah, great question. So I mean the obvious sign is software is not Getting built, right. Things aren't getting delivered, they're not being released. And then, you know, when they do, they're not of quality. You have bugs, you have, you know, clients complaining about your software. And so those are sort of like the first tried and true, easy to recognize signs. And then, you know, other things I look for is right, just the how effectively, how well does the team communicate? Is there, you know, this sort of, you know, proverbial throwing it over the wall? Right. And so a lot of teams will have developers and testing teams that are segregated and they often throw tasks over the wall to each other where there's not sort of this common understanding and focus on delivering the end result. So those are sort of two primary things that I look for is, you know, one is the software working and are clients happy and then two, are the teams communicating, you know, I guess effortly. It looks effortless when your team is really gelled.

Absolutely. So I would assume a lot of developers, a lot of engineers want to do a good job. So if you don't have a high performing team, is that a reflection of who you hired or is a reflection of communication? Is a mixture of both.

Yeah. So, you know, it's often it starts with sort of the company culture and you know, software projects can go sideways a myriad of ways. And so it may not necessarily be the person you hired. It may not even be that the company culture is not one that's conducive to a high performing team. It could just be that some of the processes aren't really quite ironed out. Right. And you might even have the right team and the right leadership in place, but you need to put some efficiencies around the process. And so that looks like, you know, communicating the vision from the top all the way down to the, you know, the entry level engineer that's on the team and making sure that everyone is aware what the company's goals and milestones are. Right. And I talk about this all the time, that engineers are making thousands of micro decisions every day when they're building some product trade offs one way or the other, right. To meet some goal or some deadline. So having a team aligned around the importance, the why behind a company's milestone really helps them make those decisions and significantly increases their throughput when everyone is aligned on what they should be building, why they're building it.

All right, So I know you work with companies and one of your services I think is a strategic, technical kind of services, but especially at the CTO C suite. So when you Talk about like communication. Do you see there's a breakdown between maybe a developer team's vision and maybe a CTO vision or maybe what's important to C Suite, what they see like KPIs and not being. Even though the team may be succeeding, they're not communicating that to the C suite CTO to let them know, hey, we actually are on track, or we're not on track because they're not using the right metrics or the right way to communicate. I guess my question, right, yeah, no.

That'S a great way to sort of look at this is like, you know, so the C suite, they have what in their brain, what the priority of the company is and what the focus is. And then the, you know, technical teams, they have in their brain what the priority is. And it's. I was talking to a good buddy of mine the other day, successful entrepreneur, and the way he explained it, I really love, and that is the C Suite, they have a really clear focus when they zoom, because they're zoomed out. They have focus at distance. Right. And they can't really see the weeds, whereas your technical teams are in the weeds and they can see very clearly opposed to what's, you know, near term, but can't really see that well, gets fuzzy when they zoom out on the vision. Right. And so facilitating this communication, you know, amongst the C suite and the technical teams really is just sort of clearing that vision up at the focal point for those teams. Right. And so an example of this is, you know, in 12 months, the C suites focused on like the 1236 month range. And in 12 months they want to, you know, release some software for some reason. Right. And the technical team is focused on the next two to three weeks. Right, because they're focused on, I got to build this thing. Right. For this reason, when you combine those visions, you know, from the technical team and the C suite, what the technical team is able to do is say, hey, I know we're supposed to get this thing done in two weeks, but in the grand scheme of things, that might not be that important. Right. And so they can punt on tasks that are otherwise a higher priority to them, you know, technical debt, as an example, and then focus on delivering the overall solution to reach the company's milestone.

Nice. This might be a weird question that the. Not only the C suite and CTO and development teams, how do you know they're even developing what's right for the customer? Well, like you mentioned, sometimes they may be developing something and it may be like, hey, this Feature really isn't adding any value. It's not adding money to the bottom line. It's not adding a better user experience. So maybe we can drop it and not prioritize it so much.

Yeah, so that really starts in sort of the research and investigation phase of any product development life cycle. Right. And so that's something that I often help companies with is should we even build the thing right. That we've, you know, budgeted to build? And so that happens a number of ways. One, if you already have a product and customers are asking you for some enhancement, then you have demand for the thing that you're working on. And then you can do, you can conduct research for your target audience using prototypes. You don't have to go build a full fledged software application or feature enhancement before you go test whether or not this will really add value. So getting that feedback early, before you even start building, because that's the most expensive phase is the building and then the long term maintenance of whatever you build, getting that feedback ahead of time to make sure what you're focusing on is really helpful. And there's a couple ways that you can do that, especially when you already have a product out there. Right. You can look at usage data of your current product. Right. So if you have a mobile app or web app, customers are already logging in, they're already clicking on buttons, they're navigating throughout the app. You can see where they're going, where they're spending a lot of their time. And so where they're particularly engaged is probably an area that you want to focus on either improving or building tangentially related features and services around in your product.

Nice. So I guess once again, communication wise, I could see that maybe a C suite or your CTO has a reason for wanting to have maybe an obscure feature be released in the next Sprint, unbeknownst to the development team, because maybe your top client is requesting it. Have you seen that as maybe, maybe if they just give a little more information to the development team, like, hey, we lose this contract, then we're toast. Like, I mean, yeah, maybe being a little too guided sometimes.

Yes, 100%. So actually of a really good example, just from my career history where we had a large client and an opportunity, we were off running on our strategic long term mission of the software that we're building. And we had one of our largest clients, which, you know, made up, I want to say about 5% of our revenue say, hey, we need this piece of software in order to continue, you know, renewing our contract with you. And so what I did as the CTO at the time was go and, you know, amongst the executive team, figure out what the real impact to the business was. And that's actually how I understood that it was roughly 5% of the business's revenue, which is a large chunk. Right. And I was able to communicate that down to the technical team. And when they understood that, they were significantly more motivated to pause what they were currently working on to build out this, in this offering to help us retain that client. And they did. They worked hard, they delivered it, the client was blown away, re signed the deal, and everyone's happy.

Nice. So besides communication, any other signs that maybe you have a team that is not up to the task? Or do you see sometimes like a development team choosing a framework just because it's the hottest and latest framework that's going to take a lot of time to develop. And the CTO is like, you know, we don't need that. We just, I mean, do you ever see that type of kind of dynamic going on?

Yes. So when it comes, there's a couple other signs that you can look at. Right. Like, part of that is morale. Right. If your team is generally like not, not all that happy, they got the Sunday scaries, the dreading coming into work on Monday, you know, that's a good sign that there's some room for improvement. And there's, you know, various ways to attack that, you know, that side of the problem when, when it comes to, you know, engineering teams, like we're all technologists, you know, in the technical side of the house. And we, we love to learn, we love to experiment with new frameworks and new tools because of the promise that they bring as well as also, again, because we have careers to manage too, we want to continue to build our skillset. So often what I'll do is if there is a new tool or new framework to be introduced, that conversation goes pretty much like this. I offer to the technical team to, hey, let's build out a prototype using the new technology, let's vet it, let's test it. You got to get, you know, real hands on keyboard and a real, a product that's produced and used in the real world. But I typically like to delegate to the team as a whole, right. So I want it to be a group decision. So there's buy in. Right. And again, that helps with morale. And when you have buy in, people typically will hold themselves accountable to whatever standard they've, they've been set. And so I leave it to the team to decide should they implement this tool, should they use it? And then I also say, hey, but keep in mind the reason behind the timeframe, the timeline that we have in place for this thing that we need to build. And so giving, I give to them, those are sort of the constraints. They can go off and then make that choice. And when they make that choice, they own it, they stand by it. And sometimes they do implement using the new technology, sometimes they say it's more effort than it's worth to implement the new technology, but they're happy to have the experience and then the autonomy to make those decisions.

Nice. All right, so you have good communication in place, you have the right tech stack, you're raring to go, see everything's humming along fine, but you just get a contract and now you need to scale up this team to handle even more work. What are some key enablers to have in place or that you need in order to scale effectively then?

Yes, so that's one of the things that I often help companies with, is how do you scale your engineering teams? And then, you know, I'm actually one of the topics that I've been talking about quite a bit recently is when you should use a consulting company and when you need to scale fast to reach a deadline, meaning you want to add, you know, cooks into the kitchen. Using a consulting company can help out a lot in that area. It gives you sort of this, this on demand scale of power, right, of delivery, you know, capacity essentially. And then, you know, when it comes to scaling a team internally, it's not as fast, right, because it is important to hire people who will fit into the company, fit into the culture, right? You know, whatever it is that you as a company has decided for your culture. But some things that help effectively is, you know, you want to have extensive documentation for how to get a project up and running. Because when you onboard a developer, you want them to be able to hit the ground running with getting their computer set up and their code base set up. And then you want it to be pretty easy for them to ramp up to that code base. So another thing that I often recommend is pairing, you know, a new engineer on the team, no matter their level of seniority, pairing them with someone who's tenured on the project because they know where all the skeletons are buried and they can, you know, help ramp that new engineer up to speed much quickly than them, you know, just diving in, reading docs, trying it out, right? When you compare them, while it does reduce the capacity of that current Engineer to help out. Overall, it brings the team's velocity up much quicker, and so it's a net positive to the organization.

Nice. So you mentioned sometimes, you know, a lot of companies need a consultant to get started. What are some red flags or what are some things you think a company should look for when looking at a consultant? Because I think a lot of times companies, I'm not saying consultants are bad, but sometimes certain companies give consultants a bad name just like anything. What are some things you say, okay, you need a consultant. Here are some things to look for, to know you're getting something that's legit or something that's really going to be beneficial.

Yeah, 100%, actually. You know, I live in the space, right? And so, you know, time and time again, a client will come to me and say, hey, I paid this freelancer or this consulting company a million dollars and I got, you know, this to show for it. And so, and I'm always like, you know, I'm happy to help and I dive in and we work from there. But there's a couple things that I tout when it comes to using a consulting company like Vertis Labs, and that is one, you know, make sure they've done it before they're tried and true, right? Especially if you've got like a recommendation, if someone else has told you about them, they've done a good job for them, then, you know, there's a higher degree of trust there, right? You can touch a product that they've built, for example, so look for portfolio products, right? They've built that you can, that you can use. And then two, whether you are hiring consulting company or, you know, in house, technical team, one of the biggest things that we do at Vertis and one of the biggest things that I tell my clients is whenever, you know, you're managing your project through whatever project management tool you're using, if the, you know, the product team, the technical team tells you that is done, you should be able to touch it, use it, fill it, right? And so I, very early on in the development life cycle of the projects that I run, we build out the test environment, whether that's on your iPhone or Android phone, for a mobile app or web app, there's a test environment that my clients can log into when I tell them something's done to actually use the thing that I said is done. Because if you can't touch it, it's not done. That's my general philosophy. Because there's, you know, with software, because it is complex, there's a lot of places for bugs to hide. Right. You know, like I said about the skeletons earlier. So that's very important, I think as a part of the, you know, project management aspect of making sure your software project doesn't go over time and over budget.

Nice. So I also know some companies worry about ip, so we're not going to have consultants because they're developing it for us, say. And what happens if they take what we have, rebrand it, you know, white label it and go off with it? Do you see that as a concern or is that something you work out in a, I guess in an agreement before you do a consulting engagement?

Yeah, of course, you know, we put the NDAs and MSAs and all that in place as, you know, standard business practice. But I also like to say, you know, like you, the founder, the CEO of your company, you know, how much work it took into building an actual company and an actual product. I think it's highly unlikely that someone can take your code and your idea and go build that in the same timeframe that you're working on it and get to market. Just because it's, you know, building. Running a business is very complex, right? It's actually, it's not very complex, but it is hard, right? You have to, it takes a lot of effort, right? You've got connections that you've made, right? You've raised, you know, raise capital to deploy the capital, you've built the teams, you put all of the operational software in place, right? So you know, of course, you know, IP is protected by contracts and then, you know, the standard consulting agreement is, you know, whatever we build for our clients, the client owns wholly. Right. But I think also the risk is lower just because it's difficult to go build a business.

So you did mention you usually work with smaller and mid sized companies. So how do you help the culture to say, hey, we have our core development in house and not make them feel threatened if they did have a consultant maybe doing their features as well? Do you ever work in tandem with the inside development so they're developing and you're developing at the same time or is that something you see working?

Yeah, 100%. So that's a really good question. Typically when we engage with a client who also has an in house team, what we do is we carve out, you know, if we are building a particular feature set or a new product and in tandem with an in house development team, we carve out lanes of responsibility. So in house team focuses on what they're focusing on. We're not stepping on their toes, we're focused on what we're focused on. And then sometimes we embed, you know, with those teams where we can help provide some of the technical expertise, deeper technical expertise, especially when we are tasked with helping a piece of technology scale. So let's say one of our clients has become successful, right. You know, which is kudos to them. And they need to help with performance or scaling the application. We can embed with the team one to help them learn how to, you know, set up architecture that will scale, set up their database that, you know, the DBA type work that helps them scale. And so we're teaching them those technical skills, which is a faster way to upskill your team than having them, you know, go learn it on their own. And so I think that mitigates just, you know, the fact that we, we approach it as if we're a partner to, you know, our clients. Right. And our goal is to make them successful. Right. That's how we become successful. Because as you know, a lot of the consulting industry business is word of mouth and kind of how I just said before, by doing good work and having those references and recommendations.

Nice. So I think you touched on this one. What are some key ways that people can measure success from working with a consultant or even their in house engineering teams? I like having a hands on, making sure it actually does what the team says it does, but and also delivering on time. Are there any other ones that you think people should keep a pulse on?

Yeah, I think so. And so I think, you know, it kind of depends on where you're in your product development life, you know, journey, you know, if you have an idea but you haven't tested the market, a mark of a good consultant is someone who's gonna, you know, ask you those questions about, you know, is this idea tested? How have you tested it? And if not, you know, offer to help you validate the idea behind that market. Another good thing too is, is they are often, they, they are frequently engaged with you. All right, if you're, you know, the CEO and you have this idea. So oftentimes when we're running projects for clients, we meet, you know, multiple times a week. The minimum recommendation that I recommend to my clients that we meet is three times a week when we're first getting started. And as time goes on, it can reduce to sometimes two times a week, but it's usually no less frequent than that. And then the third thing that I do that I think is a good mark of a good consulting Company is we have, we have recurring meetings scheduled, right. They're already preplanned. Where we're doing, I call it a project health check, where we check on the budget of the project, we check on the timeline to make sure we're on track. And again, combined with the fact that the client can touch it when I come into that meeting and say, here's where we are on the progress, they know that it's there. So, you know, being transparent about, you know, the burn rate of the cost and the timeline, that a mark of someone whose intention is to do good business and to deliver on what they say they're going to deliver on.

Nice. So, you know, nowadays generative AI, the past few years has been a hot topic. I know you have some service that has something to do with generative AI. How does that play into what you see, the industry, where it's going? Do you see now more startups like, hey, we don't even need to worry about it. We can generate an idea with the AI and then outsource it to a consulting company to a quick POC to see if it's going to fly. Like, where does gen AI fit into where you see consulting and software development nowadays?

Yeah, that's a really good question. So I see it fitting in in a couple different ways. So personally, I use it to brainstorm, to help me come up with ideas, to, you know, learn a particular, you know, details about a particular industry if I'm, you know, going into a new industry with a new client. And then we also use it at fortis for helping us generate content for, you know, when we do, you know, when we build products for clients, you know, they often need websites with them or if they're an established client and they want to refresh. We use it for content generation as well, for web and social posts. And then, you know, for companies who are embedding AI into their software, we often help them figure out how to leverage it, how to embed it. So, you know, the classic example of using gen AI is chatbots, where companies will often, you know, have a, you know, they're in their product. The ability for clients to just talk to an AI and help them through some process. I have seen a lot more success on the gen AI front where it helps reduce the tedious nature of data entry for our clients and so within their products for their clients. And so we'll use it as sort of this back office tool where maybe the client doesn't even necessarily know or the, you know, the end user doesn't even necessarily know that there's Gen AI built into this product. But behind the scenes it just, you know, makes the product the, the user experience more seamless. Right. It reduces the friction for a client, for a user using that product. And so I think that's the way that it's going. You know, we also use tools like Copilot for speeding up the development. Right. It generates quite a bit of code, which is nice, but I would warn against, you know, coming, generating your idea and then outsourcing it. It's like any software product, you know, if you outsource it, the people you're outsourcing it to, unless they're embedded in, you know, and meeting with you regularly, don't typically know your domain and don't know what you are really trying to achieve. So you really want someone that you can work closely to, closely with as opposed to sort of outsourcing it and saying, hey, build this thing. Call me in three months when it's ready.

Nice. So GCG and I then helping to scale teams and augment them rather than replace them, it sounds like.

Yeah, I think we're a pretty good ways away from engineering teams being replaced. You know, I would say somewhere in the 5 to 10 year range that definitely, if you're not using some of these tools to help your technical teams, highly recommend it. One, it makes their life easier and boosts their morale because they enjoy using them. And two, it will, you know, it's sort of hidden, but it does increase the efficiency of the teams and it's sort of hard to measure but you know, because I'm in this industry and I do this and I use them myself, I can say with a high degree of certainty that it does increase the efficiency of the teams.

That's what I was going to say. How would you rate Genai? Is it overhyped, properly hyped or underhyped?

That's a good question. I will say based on some of the investments that we've seen over the last couple of years, it has got an enormous amount of hype. I think it does make sense for the big players in the space, the Azure, the aws, Microsoft companies, to be betting heavily on this because it's definitely here to stay. Just like the Internet was here to stay when it came to. I don't necessarily think that, you know, the medium small to medium sized business needs to go out and dump a bunch of money into Gen AI. I think they need to wade into that water like gently, slowly and with intention. Right. And so I Think they should spend their funds, at least initially on the investigation of how can we leverage this to, you know, increase the quality of the. Our product or the efficiency of our internal operations are the sort of the two major areas where you can, I think these companies will see the biggest benefit from Gen AI Technologies.

Nice. How can companies make sure they're innovating and not hiding their head in the sand like oh, AI, it's a fad. Just like you said the Internet. I remember when people were saying, ah, the Internet's a fad, it'll never replace us. And Bam, you know, 25 years later, right.

It'S done. So it's done.

Yeah, I would say they should definitely be spending, they should be allocating in their budgets some amount to investigate how Gen AI can affect their company because if they're not thinking about that strategically, I think they're going to be behind the curve as time goes on. The technologies are advancing rapidly, the capabilities are advancing rapidly and there is some real world use cases that companies can leverage to improve their customer experience, their product and internal operations. So at a minimum, you know, set aside some budget, you know, during your, your fiscal year planning to research how these technologies can make an impact in your company and then, you know, with the intention of like, you know, having real metrics to back them up.

Right.

And so, and then, you know, once they've done that, that work, they can go full bore into whatever it is that is revealed from that research effort.

Okay, Andrew, before we go, is there one piece of actual advice you can give to someone to help them with their DevOps development engineering teams and the best way to find or contact you?

Yeah, absolutely. So I'm going to stick with the theme of, you know, teams here because that's, you know, one of the things that I love the most. And I'll give two pieces of advice. One, you know, bring the engineering team along in the early conversations of whatever product, idea or initiative that you have with your organization. Again, you get early buy in from them, which means they're going to, you know, attack the problem with a higher degree of enthusiasm. And then two, one of the biggest things that I've been doing lately that I've been enjoying is we, you know, one of my, our big technologies is Node and Typescript and Expo. I'm a big fan of the monorepo pattern and leveraging things like database models and global services in the model repo across your front end and your back end. And by doing this you can reduce the speed at which it takes to build a product from scratch. And so I would say if you haven't looked into that, I would look into the mono repo patterns with the Node technologies and you guys can reach me at duncanvertis Labs IO or go to Vertis Labs IO and for links.

Of everything of value we covered in this DevOps Toolchain show, head on over to test guild.com forward/p171 so that's it for this episode of the DevOps Toolchain Show. I'm Joe. My mission is to help you succeed with creating end to end full stack DevOps toolchain.

AwesomeMess.

As always. Test everything and keep the good. Cheers. Hey thank you for tuning in. It's incredible to connect with close to 400,000 followers across all our platforms and over 40,000 email subscribers who are at the forefront of automation testing and DevOps. If you haven't yet, join our vibrant community@testguild.com where you become part of our elite circle driving innovation and software testing and automation. And if you're a tool provider or have a service looking to empower our guild with solutions that elevate skills and tackle real world challenges, we're excited to collaborate. Visit test guild.info to explore how we can create transformative experiences together. Let's push the boundaries of what we can achieve.

With lutes and lyres, the bards began their song A tune of knowledge, a melody of code through the air it spread like wildfire through the land Guiding tester showing the secrets to behold.