Hi, I’m Michael Hunter with Uncommon Teams. Welcome to the Uncommon Leadership interview series, where we talk with leaders in software like you about their journey to seeing people as people and leveraging the unique gifts each of those people bring.
Today I’m talking with Matt Domo. As CEO of FifthVantage, Matt helps his clients create clear and actionable technology strategies that power digital transformation for business success. FifthVantage’s goal is to help clients modernize, innovate and grow by implementing strategies, technologies, and processes that reduce time to market and create speed and agility in the business.
Matt Domo 0:50
Thank you, Michael. I’m excited to be here! Thank you for the opportunity.
I’m excited to have you here and to see where our conversation goes today!
Let’s start that by telling us: what helped you first recognize that leveraging each person’s unique gifts might be valuable?
That’s a great question.
So, I started my software executive journey at Microsoft. I started as a developer and then went on to become an engineering leader.
What I found as a developer is I, myself, and my teammates all had different strengths when we were developing different elements of the software, even though we are working on the same project. We all had different strengths and capabilities and approaches to problems.
So, as I started to become more of a leader, as opposed to an individual contributor, writer of code, it helped me put things in perspective. I started to figure out with my leaders as the organization grew, “Let’s make sure that John is working on this element of the project because he’s skilled on algorithms. And let’s make sure that Ann, who’s working on this element of the project, who’s more skilled on protocols,” and start to specialize that way. So that really helped build out the team.
I carried forward that experience as I continued to develop different software products.
Do any times stand out, when you either noticed that the people you have thought should be working on something aren’t the right people, or when giving the right people on really made a big difference?
Yeah, I could talk about I can talk about both of those elements.
So, let’s talk about getting people in the right seats.
Microsoft did a good job of training us. Some people like this book, others don’t. It’s called Good to Great. The elements of the book that stuck with me—I’m not a big book quoter in general, but you can get pearls of wisdom from different books and you can apply them how works well for you.
One of the elements is if you put people in the right seats on the bus, you’ll go in the right direction. It is absolutely true. Software developers all think that they get power if they are managers. Well, some people aren’t organized project management-wise and even more, they’re not great people managers. When you’re building a software development team, it’s as much about the emotion and safety and bonding in the team as it is writing good code. And so, it takes a bit of experience to recognize who’s a good software manager versus who’s a better architect and technology leader, because they’re often not the same person. As an engineering leader, you’ll make a mistake if you try to do the one-size-fits-all approach there. So that was one element.
And then back to: Did you ever see someone in the wrong job? Yes. I’ll talk about one.
I built a voice product from Microsoft called Speech Server. It was a version one. It was a combination of an acquisition, a project from Microsoft Research, and then a bunch of engineers that I brought in from my past. It was Bill Gates’ pet project, so a lot of pressure. We had to co-develop the software with Intel, and at that time, Intel and Microsoft weren’t getting along. And so, they were using it as a model of how the companies could work together.
I noticed one of my leads was working on one element of the project as a leader and it was not operating efficiently, not the software but the team. Their focus was on the quality and the improvements we needed to make. He was an engineering leader of this capability from the acquisition that was melded with what I talked about. So, you have experience, but it just wasn’t flowing. The speech recognition had a high error rate, so it wasn’t recognizing things.
So, over the course of a month or so I dug into that and found that he just wasn’t grokking the speech recognition elements, what he was describing, even though he was building a server around it. He was much more adept with how to integrate with telephony systems, you know, voice-enabled systems and building that. So we moved him to take over that job and backfill them with a leader that understood the other elements.
His morale wasn’t the greatest after we did that, right, because everybody was like, well, “That’s the star of the project,” etc. And I said, “Look, X, we can have the best voice recognition in the world, but if someone can’t access it, it doesn’t matter. And what you’re doing is super critical because it’s the entry point into the product and it’s got to be right. And we know you have the technical chops for it, and I’m excited to do it. And if you do a good job, when you do a good job, you’re going to see that it’s a good move for you.”
So that’s one example.
And how did that turn out? Did they see that was right move?
Matt Domo 7:18
He did. He wound up doing an excellent job and you know, his part of the product set industry benchmarks for performance and reliability. It was better than anything else that had been in the market, and I attribute that to him. He did a really great job. But it took him emotionally a little bit of an adjustment because he felt like he was being dinged.
So, in the in-between time from when you told him, “Hey, this isn’t the right place for you. We’re going to get you set up for success,” and then to where he recognized, “Oh, this was the right move. Yeah, you’re absolutely right.” The in-between time. How was it for him did you think? How did you help him make that transition?
So, he became quiet.
He in general was somewhat of an introverted manager, which is fine. They’re also the most contemplative and humanizing managers. But he became more quiet than normal. And so that’s when we started to recognize he was frustrated because he was trying to focus on that part and my development director and I were like, “Okay, how do we motivate? What are we going to do to get him to see this is okay? We know it’s the right move for him. We know it’s the right move for the product.”
We just started praising him. Not for the sake of praise. Pointing out, “You’re making these improvements and it’s making a difference. And you are having an impact and you’re doing a good job of filling out the rest of your team.” Again, not token bones that you throw to someone. Really pointing it out where it made sense. And then his team started to rally around him a little bit as they got to know him and his personality and his ability to do it.
It took about six months before he really hit his stride. I was blessed. My development director was just an excellent leader. And so, he was able to pull the best out of him and it worked out
How did the rest of the team react? When you pulled him off from his leadership role into a different more specialist?
This product was a combination of a research team and acquisition and then seasoned Microsoft vets of a shipping product.
Candidly, the first little bit, I was brought in to fix it up. They’re like, this is strategically important for the company. We need someone that can pull this together, but it wasn’t operating well.
Within my first three months, I pushed for this change, and people got scared.
They’re like, “Okay, if I’m operating like that, or what other changes is he going to make or am I going to lose my job or, ….” And this was one of many moves we had to make as a team.
But the strategy I showed is “Look, this is the benefit to the customer. This is the benefit of the product. And this is the benefit to you. And you know what was happening previously wasn’t working. We have to change. Here’s why.” And going back to those benefits.
Yeah, people were scared and I know it, but had to do it anyway. And so, keeping with the people and building faith and having them see results of the changes that they made personally, and then we did. Over time, it worked out. We wound up within the year and a half having one of the highest morale teams in the whole company. But it took a little bit and it was painful.
That’s a fabulous shift. What were some of the other painfulness that happened over that shift?
Well, like I said, some people got scared because we did also let some people go. They weren’t performing well, or they weren’t a fit for the culture we were trying to build and were overly negative on everything to the point they weren’t contributing. We kept saying, “Hey, we need you to participate.”
As a leader, when you have to change an organization sometimes you have to make some of those moves. And so, a couple of the people were respected from an interpersonal experience, but their contributions to the corpus of code and helping us move forward, they just were too negative or jaded. So, we let them go.
And so again, that added some of the fear of change, you know, the whole “Okay, change is good. It can be good, it can be bad. It all depends on how you lead it.”
Over the course of like three to six months, people started to see “Okay, we’re making positive momentum. We’re hitting our milestones. We’re not killing ourselves to do it. Quality is increasing. We have predictability.” All the things you look for in an engineering organization started happening. That brought buy-in.
I was transparent with the team, “I’m done making changes. We have the team, and I have immense faith in you and we’re going to go do this. And now it’s our job to go make it happen.” And so, that was the whole element of it.
That sounds like you really helped that team through a fundamental transition from, “Here’s how we used to work,” to “Everything’s kind of all up in the air. And Matt says things are getting better but we don’t see it yet,” to “Oh my gosh, we are amazing now.”
It took about, like I said, about 18 months to get it all fully through.
How has that experience informed the way you show up in similar situations later on?
I had some more tools on my belt.
Another thing I’ve learned over time is that it’s not a one-size-fits-all. If there was a Swiss army knife for leadership, everybody would have it.
What it did do was inform making decisions that I had to make in future organizational transitions.
One was not to be fearful of making a change. If you see that you have to make a change, first try to see if you can fix the issue. There’s a multitude of things that could be affecting it. But if you know that the person is in the wrong seat, or their skills aren’t being leveraged, then you as a leader, it’s on you to kind of pull that forward.
That really helped quite a bit. It helped me be confident.
You know, as a leader, you have to demonstrate confidence. Not cockiness, confidence. Because people will follow someone who has strong energy.
Those transitions helped quite a bit and I kind of figured out, you know, “Hey, I can do this. I’ve done it before. It’s okay.” And it helped quite a bit.
With that experience, and where you’ve done similar transitions since, where do you fall on the spectrum between letting people just sort of figure out what’s going on their own, to really working intensively one-on-one with each person to help them understand what’s going on and where they fit and where they want to go and how that fits with where you’re taking the team?
That’s an awesome question. It’s going to be a windy one.
You know, I took a step back as a leader and said, “What are my strengths? And where am I not strong, and where I shouldn’t focus.”
I put energy into the things I was good at, and then looked for leaders at all levels.
People think leaders are people managers. No.
In a software development organization, some of your technical leaders, architects, etc. are even more important because they’re looking over the code.
Leadership development was one of my strengths. So, I doubled down on investing in the senior technology leaders, but in terms of the architects and the like, and my directs and their directs about how to develop them.
As we started putting people in the right seats, whenever I asked people to have a one-on-one, I don’t ask for status. I have status meetings. I don’t need that. I always ask them, “How’s the weather? What are you looking to do? What can I do to help you and by the way, what do you want to grow up to do? What motivates you? What do you want to achieve?” And spend a lot of time on those things.
I believe in radical candor. People are open to feedback generally, as long as you don’t beat them over the head with a bloody bat. If you give them feedback and like, “Hey, this area probably wasn’t your best work, but this other area over here, you’re doing a great job.” Balanced feedback where it is and that’s kind of the formula I put together and it works.
Have you always approached leading people through change and that passion, or how have you come to that over time?
Well, like I said, I came to it over time.
Each individual situation is different. There are principles that you can apply to recognize that change needs to be made. But again, each situation is different.
One of the most important things you can do is to focus on the people. Help people go from where they were to where they need to be.
And that takes a lot of being in front of people and collaborating and giving feedback, giving encouragement.
A lot of that is the culture of the company you’re in the group you’re in the team you want to build.
Tuning the culture takes a while.
And, like I said, every situation is different.
Sounds like this is one aspect of building uncommon teams that you’re really comfortable with and do really well with.
Is there an aspect of that process that you are struggling with?
I’m decent at process. I’d say I’d have adequate skills, but I obsess over it. I’ll find myself obsessing over a process because, you know, it should just work. They’re pretty straightforward processes and it should just work.
As a leader, one of the things I also dig into is, if there’s a problem, I try to dig deep and understand what’s going on.
I surround myself with leaders that are more adept at process, like it, are excellent at it, and are more patient with it than I am. And I kind of let them go.
As a leader, realizing the things that you’re good at, that took me a little while.
Then I realized, “I’m not helping. I’m making things go. Yes, we’re making improvements, but at what cost?” And so, I just said, “Look, I’m not the person for this. I’m gonna go find people and let them go do it.”
Yeah, I find the same thing. That understanding what it is exactly that I’m struggling with, is way more challenging than helping my clients do that. I can’t tell you how many times I’ve had a conversation with a client or a friend or some random person, helping them through something that they’re struggling with. And then after we depart company, and I’m sort of reflecting back over I say, “Oh, everything I just told them, I need to do myself.”
Yeah. I understand.
Like, I’m not perfect. If you poke a fork in me, water and blood is gonna run out, just like anybody else.
I had some good mentors that helped me. I’m a big believer in mentors. I had some good mentors, and they were like, beating me over the head: “Matt, what are you going to be great at and what are you going to let other people be great at?”
After enough butts in the head, you start to realize, “Hey, I need to listen to these people.” And so, I did, and it was a key element to help me succeed as a leader.
You’re taught in these Type A software organizations, “Don’t show any flaws.” That’s actually the worst thing you can do because people know you have them. And if you don’t embrace them, and you don’t be yourself and authentic, it actually hurts as well.
Even though I’ve had several engineering leaders tell me, “I went into software so I didn’t have to deal with emotions,” we can’t get away from them.
Some people are emotion by nature, their emotions is what helps them navigate the world.
Other people are data driven. I’m in the data driven camp.
But some people are super passionate. And so you have to let that passion flow.
You kind of have to go back and say, “You know, you might be right, what are the data points you’re using to come up with that?” But you do have to let them express themselves in the way that works for them.
And even those of us who are way more comfortable with the data, we still have to watch out for our emotions, or they show up in really awkward ways.
I agree with you.
This has been a great conversation, Matt. We’re just about out of time. What else should I ask you?
That’s a great question.
You know? I don’t really know, to be honest with you. I thought about that. We talked about that before the conversation and you know, I really don’t know.
That’s a fair answer.
What do you want to leave our listeners with today?
Leadership takes practice.
It starts with the Three Finger Rule.
When you’re pointing out this way, three fingers need to point at yourself.
You constantly should do some introspection of yourself and understand what are you doing to make the situation better? What are you not doing to make the situation better? And adapt.
Like I said, there’s not a Swiss army knife to this stuff. You have to adapt as a leader to your people in the situation too, and you have to be humble enough to do that.
And that’s really, really important. And that’s a lesson that took me a long time to come to grips with.
So, I thought I’d leave that with you. It’s possible, but you have to make an effort to do it.
Thank you so much, Matt. It’s been a great, I’ve enjoyed this conversation.
Where can people find you?
I’m on LinkedIn. I’m a pretty open networker, so you can find me on LinkedIn. Matt Domo.
Or drop me an email. I’m firstname.lastname@example.org. Happy, happy to help anyone I can.
(Find Matt’s company, FifthVantage, on the web and on LinkedIn.
If you’ve enjoyed our conversation today, you might enjoy my newsletter. I fill it with inspiring stories about software leaders, just like Matt and just like you, who are learning how to leverage their strengths and those of their team. You can sign up for that at the top of this page, and read the archives at uncommon teams.com/newsletter-archive.
Thanks for listening. Have an enlightening day!