Building Motivated, Engaged and Impactful Teams

Tullio Siragusa (00:12):

Good day everyone. This is Tullio Siragusa, your host at Tech Leaders Unplugged. I am getting unplugged today with Chris Holland, who is the VP of Software Development at CertainPath. Hi, Chris. Good to have you today on the show.

Chris Holland (00:26):

Good to be here. Thanks for having me.

Tullio Siragusa (00:28):

We're talking about building motivated, engaged, and impactful teams. And the tagline or the topic we're going to explore is really exploring life and possibility beyond KPIs. This is an interesting topic that I think we will hopefully learn some new things or at least reiterate things that might be maybe overlooked often enough. But before we do, let's get to know Chris a little bit. Tell us how you got here. Tell us a little bit about yourself. And again, welcome to Tech Leaders Unplugged.

Chris Holland (01:02):

All right, thank you. Yeah good to be here. So I've been in software since the mid-nineties. It's been a while doing web development. I, I started as an individual contributor, and then I got into leadership around 2006. Since then, I've, I've served teams of different sizes from a handful of engineers to, you know, grown teams to a couple of dozen up to like, you know, 40 engineers. I've worked in the SaaS space content commerce. I, I worked on different types of applications, and again, it's pretty much all web applications. And yeah, and I just most recently joined CertainPath with a really great team, great people are very happy to be here, so.

Tullio Siragusa (01:50):

Excellent. Chris. Let's dig right into it. I think right before we went live, we started talking a little bit about Yeah. The context behind this conversation today. And you said something interesting it's easy to get very focused on the transactional level of your work, especially if you're a developer. That is, the metrics you need to reach, the production effort you need to reach etcetera, etcetera, etcetera. But it's in, you know, I find it that developers, you know, my people kind of look at them as very technical, are actually, in many ways, artists, you know, they're creators. So artists and creators also like to have a certain amount of autonomy and freedom. Tell us a little bit about what your thought process was related to this particular topic.

Chris Holland (02:40):

Yeah, and, and it's always interesting because, you know, as, as you build bigger and bigger teams, you want to be able to see sort of you want to have you know, key performance indicators and kind of track metrics on, on how your team is doing, right? So if you manage, for example, in sales, right? If you manage a large sales force, you know, you, you can track how many outbounds people have, how many callbacks, how many leads they've converted to, you know, to prospects, and how many prospects they've closed, right? There are a lot of very tangible metrics that translate directly to business success. If you look at marketing, for example, right? There's just a lot of metrics there. Again, you know, if you did a marketing campaign, how many page views, how many conversions you know, did they drive? And in engineering, you know, there, there are similar pretty meaningful metrics you know, that, that we can track. However if really, you know, if, if we look at leadership through the lens of, of sort of polarizing on these metrics and, and by sort of defining a team's success sort of making these metrics look good it can get into some pretty you know, toxic behaviors and then you, you end up sort of achieving behaviors that kind of, that can be counterproductive to, to your business goals, right? So if you look at code quality metrics there are ways, for example, to kind of sweep things under the raw rug, you know, such that your code quality tooling looks good, but you know, your metric looks good, but you know, when you look at your code, it's, it's actually less maintainable. There, there are a lot of ways to sort of game the system with, with different types of metrics, you know, code coverage. You know, we talk about test automation and, and having code coverage against your code. Well, you can actually write a lot of unit tests that cover your code, but they don't actually test anything, right? So you may look like you have 95% coverage but you are actually not testing anything, right? So there are, there are often ways to sort of, you know, game the system. And if you polarize your teams on this, you can achieve a little bit of counterproductive behavior. And, and, and to me, I find these metrics still very valuable to track. But I like to look at them in terms of key signaling indicators, not key performance indicators where I keep these close to the vest where it's something that I look at with my boss, but I don't necessarily p pollinate these metrics to the team because I'd like to focus on the better practices first. And then if you focus on the better practices and you motivate your team to embrace and adopt those better practices, then the metrics will come as a byproduct of it. And, and, and that kind of goes back to this topic of, of, you know, leadership style, right? Are we here to really, as leaders to really focus on the accountability part of leadership? Or are we here to really bring motivation and coaching to the table, such that accountability now becomes more of a byproduct, right? An acknowledgment of the process upstream, sort of, you know, working and this, and, and I'd be curious to see sort of, you know, what, what, with all the guests that you've had on your show, sort of what they've what their experience is with this.

Tullio Siragusa (06:27):

It’s a big topic because we are also talking about what happens when you have codependent leadership models, which are not equivalence based, right? You have someone who is in charge and the rest are responsive, kind of like a teacher and children at school, right? They get to test, the teacher administers the test, and the children have to remember the information and do well on the tests, right? So, in essence, metrics and compensation do drive certain behavior, but what you're saying is if you don't have alignment in what motivates people and how it meets people's needs, maybe to be adults, not codependent children, then you end up creating a model where it could be very toxic cause you're just basically trying to meet the quota or the, the metric number. So, in your opinion, how do you balance the need for accountability and, you know, moving it towards a self-accountable model versus one where, where you have to do it because you're being measured on it, what's worked for you? I'd be curious to see in terms of what you've adopted that enables people to say, I'm self-accountable. I do this cause I want to, because that's you know, the point of being a mature professional. What are your thoughts on that?

Chris Holland (07:48):

Yeah. I think motivation and coaching are, are super impactful, right? So, so there's always going to be tension a measure of tension between sort of, you know, quality and, and, and, and speed of, of delivery, right? Like, I need to get this feature out the door right now but also it needs to be built well, right? So I can build on top of it later on. And with, and especially in software engineering, I think there's this, this balance that can be achieved where the, the, the quality can actually drive speed of delivery. And that comes down to a level of acumen that just needs to be attained by the engineers, right? And this is kind of where coaching comes to play. It's, it's to really as, as a leader, really take the time and, and diligently explore ways that things can be built the right way such that you can also deliver faster, right? And, and, and I know that, that everybody's knee-jerk reaction is like, sort of better, makes me slower. But I kind of like to sort of try to break this and to actually look at it the opposite way, where better will actually make you faster. And yeah, so, so there's I think coaching is a big part of it.

Tullio Siragusa (09:33):

What about the actual structure that's in place? I, I know for example one of the promise of the agile methodology was to empower teams to work more in a collaborative team kind of effort with less command and control structure. So it forces you to really collaborate and work together. And if you are the sort of weak link, the team will call you out on it. So the accountability is actually not to just one person or a metric, it's to each other. What are your thoughts around, you know, the intent of Agile and how it's used today? It's probably very different, but from the original intent, do you think that's still an effective methodology to create more of an empowered team environment?

Chris Holland (10:16):

I think the original principle of Agile so if you look at agilemanifesto.org, I think are still very helpful and relevant today that embracing change matters more than adapting to a plan that people in collaboration matter more than, you know, rigid processes, you know, things like that, right? These, these are, are philosophies that I think are, are very effective. Where things get interesting is that when this manifesto sort of came out there was sort of an entire industry that kind of built around that, that was built around it. To, you know, to polarize on processes like Scrum, for example, right? And Scrum itself is a big fan of its ceremonies. And I've seen a lot of myopic obsession with sort of this process and regardless of sort of the team dynamics and the team and the realities of your business, right? To a point where there's a lot of toxicity that sort of emerges, right? So, it's, for example, it's customary, in the sprint paradigm within a scrum paradigm to, you know, ascribe points to stories and then to track points across different sprints. I found that very helpful as well. Having said this things tend to be toxic when you start comparing points across teams. Because, and it's, and, and the big irony of this is that it's really explicitly said everywhere. Do not compare points across teams, but teams tend to do that, right? It, it, it's, right.

Tullio Siragusa (12:19):

Beautiful manifesto with good, good principles that are supposed to be self-governed. But if you apply managerial skills, instead of being a leader who coaches and encourages you end up creating competitive environments. And comparison, again, going back to the parental-child type of relationship. So, so one needs to shift, is it the systems, or is it the quality of the leadership? Or both.

Chris Holland (12:49):

I think there are a number of things. So, if you look back at the Agile Manifesto website, they had a page, that talked about their 12th principles, and they said that embracing technical excellence was actually a really good way to embrace change, right? Because you're going to have a lot of change that happens in business. Your software needs to adapt to it. So you really need to ask yourself about technical excellence. And I think this, this is a thing that I've, you know, I've, I definitely value Scrum and, and I'm, and, and I've been in dysfunctional and fun and well-functioning teams, and I've learned a lot in the process. But if you don't have technical excellence as, as a building foundation, at least for software engineering teams, you're going to get in really bad places really fast. And so, I think that's the first thing that needs to happen. You know, when, when I look at companies that say we need to be agile and the first thing that they do, and they don't take, you know, companies that have challenges constantly releasing new features it's really not because they're doing Scrum or not doing Scrum, you know, adopting Scrum is not going to get them out of that hole. If they take an honest look at what their challenges are, I can almost guarantee you look, almost, you know, everybody's different. But from chatting with a lot of companies, the issue is, is always how the software is written. Things like technical debt, you know, very quickly, if you're not very intentional about the quality of the software that you write you get to a point very quickly where it's impossible to build something new without breaking something old. And when, when you start on a project you know, you start out on the project the first week, first two weeks, you are able to launch a lot of features really fast. But then you accumulate a lot of technical debt, and as your project matures, you get to a point where it takes you a near-infinite amount of time to get nothing done, right? And so, to answer your question, what needs to change, at least from a software engineering standpoint I think there needs to be a really strong recognition by, you know, all our engineering leaders out there that technical excellence matters a lot. And there are a lot of very frank conversations that need to happen among teams to really take an honest look at our ability to build something new without breaking something old. And to do this at a sustained pace, right? Like very simple concepts can we achieve that? If you've got that going, then you're looking good, you know, then yeah, sure, yeah, scrum, but I think you will find a lot of teams sort of struggle with this.

Tullio Siragusa (15:56):

It's an interesting concept. If you build strong teams that value quality and are also closely tied to understanding the business impact of what they're doing and how it helps perhaps from the competitive advantage point of view, then they become motivated from, from a personal perspective, a personal excellence perspective. But let's talk about also the challenges of today's world, right? You also have contributed to the team quite often in different locations, even worldwide. And communication becomes a challenge too. So you might have found the right talent or harmonizing them to work together sometimes is a challenge. How do you address that? And people tend to go back to the KPIs and metrics as a unifier, but Right. What I'm hearing is that's not the right unifier. So what is the right unifier?

Chris Holland (16:46):

And to be honest, this is something I have struggled with a lot and still do sort of as I, as I have grown a team through different time zones, to me the most impactful different differentiator is a time zone, right? Like, it doesn't, I've been able to work with geographically distributed teams, you know, over the US and even South America as well, right? But again, it's sort of, you know, time rate you know, where, where, where it gets.

Tullio Siragusa (17:21):

Concurrent working hours, basically. Basically concurrent working hours. Yeah,

Chris Holland (17:26):

Exactly right. Because now you can do a lot of collaboration. You can get on a video call real quick, do some, you know do a pairing session by sharing our screens. And in fact, the remote paradigm works really well because when you are all in the same office, right? You don't typically do a screen share, right? You just kind of sit at each other's desk and look at the same monitor, right? To do some pair program to kind of troubleshoot something together, right? But when everybody is in their own home, you know, like I have a really big monitor here. I can put, you know, my partner's monitor you know, screen on, on that big monitor and really have a great time collaborating. But when you have your teammates who are in a completely different time zone you know, it could be in India, it could be in Vietnam it, it becomes challenging to kind of have these, these synchronous collaboration dynamics, right? And I've, and I have struggled with this. I continue to struggle with this. What has helped is sort of having documentation, you know, so we, we learn a lot on, on wikis. And the nice thing is wikis, you know, our living, breathing documents so a couple of us in the US time zone might contribute some thoughts as to kind of how we might approach something. And then when, when the Vietnam folks get online, they kind of look at the wiki, and then they can kind of contribute their sub-bullets with their comments and counter suggestions and, and things like that. And then you can sort of arrive at a set of tenets as a team that becomes sort of your engineering principles, that we care about, right? These are our engineering principles, these are the methodologies that we have all agreed as a team that, you know, we care about these things. And in turn, this living, breathing documentation helps during the code review process, right? Because now in the co during the code review process, you can sort of, you know in the code review, you can just link straight to different subsections of your tenants’ wiki you know, as you give feedback to your peers. And, and so, but obviously now you have a little bit of a 12-hour turnaround time, you know, on, on the collaboration and you know, so things move a little bit more slowly. But if you really if you really try to document things I think it, it, it has helped me at least in, in the, yeah.

Tullio Siragusa (20:02):

You said something really key earlier about being a leader who motivates and coaches versus just managing metrics. What role, in your opinion, those continuous learning and even recognition play in getting these, first of all, the right teams with the right talent who want to succeed, who are committed to that on their own, right? They don't need to be motivated to desire that. And then obviously having the kind of a structure where that collaboration takes place and it's motivated by the desire for excellence, but what role in going back to your comment about coaching and motivating does continuous learning and recognition play in that are, are teams getting enough recognition for the work that they're doing?

Chris Holland (20:51):

So one thing that I've found super impactful is, to bake within the DNA of the team the ability to grow our own talent and to coach one another, right? To encourage pair programming for folks to learn things from one another. You know, having our own curriculum of, of topics to you know, so there are a lot, there are a lot of free online resources on virtually every engineering topic you can think of, right? And so as a team, what I've done is we've curated sort of these different learning topics in different sections, kind of a, you know, as a learning guide, basically we, we've cultivated our own learning guides and such that anybody on the team, regardless of where they're at with their current skill sets, they can look at the learning guide and, and learn different sec, you know learn different topics combined with pair programming. And I also do sort of weekly team meetings as well to kind of promote that. And so, I have some of my folks in Vietnam kind of do their equivalent as well to, to kind of promote sort of this pollination of, of, of knowledge. And I really strongly believe that the teams that will be the most competitive out there, especially, in today's markets where it's really a talents market. I mean, I know that recently there were a lot of layoffs and all these things, but it's always going to be more or less a talent market. So, are we able to grow our own talent, you know, take somebody who is early in their career and can we you know, help them grow really fast too, to really deliver business value? And, and I think being very intentional about this, and p to your point kind of developing a continuous learning curriculum, I think is, is very important.

Tullio Siragusa (22:49):

Well, that sounds like a lot of good tips. Pick the right teams, empower them, and encourage them. Make sure you have a good communication cadence in a place where possible working similar, concurring working hours, encouraging growth, continuous learning, and recognition, and don't manage, but lead people with encouragement and with motivation, I think we've captured it. Is that it? Excellent. Thanks for being with me today. Just to hang on, as, as we go off the air this is the last show for this week. I'm going to be hosting next week, , Mark Moser, who's the CTO of Thrive Works. That's going to be Monday at 9:30 AM Pacific on Thursday I'll be speaking with Charu Goel, who's the senior technology leader at Bank of America. And on Friday, James Miller, who's a co-founder at Beionce. I hope I said that correctly. But it's going to keep up with what's coming next. Just go on techleadersunplugged.com and you'll see the upcoming guests on all of our shows, as well as the blogs related to the show. So thanks for watching. Have a great weekend and see you again Monday.