My simple thought process was, show, don't tell. Let's change some things and see what happens. And we started by changing some of the decision-making. Boom, boom, boom. Features start shipping. All right, we change who's on which team.
Okay, so more features start shipping. So by the end of the year, when we got to the last offset of the year, it's like, okay, here's what's changed since that first meeting. And they're like, okay, well, what do we do? What's different? Well, we didn't change the people.
but we did change how they were being led. You can talk about a problem all you want. You can come up with hypotheses and propose solutions, but you have to show it. And the quicker you get to problem identification, showing some progress towards a solution, that gets the buy-in that you need.
higher levels of the organization. Hello and welcome to the Engineering Leadership Podcast brought to you by ELC, the engineering leadership community. I'm Jerry Lee, founder of ELC. And I'm Patrick Gallagher, and we're your hosts. Our show shares the most critical perspectives, habits and examples of great software engineering leaders to help evolve leadership in the tech industry.
In this episode, we're joined by Kevin Stewart, SVP of engineering at Splice to discuss organizational transformation, inspiring vision and empowering teams. This is the heart of leadership. And if you want to align and motivate. team at all levels. And this is an area that you're really trying to drive. You're in the right place. Kevin shares a couple of incredible stories about how you can create the same vision alignment that they experienced at splice and what that big moment was for them.
Plus, we discuss strategies for empowering teams to operate autonomously, freeing you up to focus on business objectives and strategic work. Like I said, this is the heart of leadership. So let me introduce you to Kevin. Before his time at Splice, Kevin's been a VP of engineering at places like Fastly, Harvest, Heptio, and NodeSource. As an engineering executive, Kevin's focused on building teams to build products. He's helped shape the engineering culture at a number of different startups.
digital agencies and cloud companies. Enjoy our conversation with Kevin Stewart. Kevin, thank you so much for joining us. We're so excited to have you here. Happy Friday. How are things going on in your world? What's going on right now? Well, first, thanks for having me, Patrick. It's always great talking with you. Things are crazy right now.
In a good way. There's lots going on. So I'm kind of spinning a lot of different plates all at the same time right now, but it's all good. Why I've been so excited about our conversation, you and I were talking about a couple themes.
leading transformation, inspiring vision, balancing strategic versus tactical, but including, you know, once you've established this alignment in this vision, and sort of transformed this direction is then also delegating and empowering teams to be able to, you know, expand your capacity and create ownership.
And when I was thinking about like, why is this conversation so special? It's like, this is like the heart of leadership. Like this is it right here. Like these are the big things that people need to do. And so I've just been really excited to dive in. I guess first question to jump in, like to start setting some context, you know. we were sort of talking about this story of a recent team transformation that you've been working on. And one of the things that came up was
There's this idea of there's this difference between what people think is broken versus what actually is broken. And so I was wondering if you could bring us in a little bit into that story and start unpacking the dynamics that you observed.
Sure. So this is really when I first joined Splice. And like every leader, you come into a new organization and you want to get a lay of the land. And I got a lot of different input from folks. I was doing a listening tour, meeting with everyone in engineering, outside of engineering.
engineering, obviously meeting with my executive peers, my CEO. And everyone, of course, had a different take on what wasn't working or what was broken. And all of it's valid if you put yourself in the perspective of that person.
From a product manager's perspective, these things are broken with engineering. But if you go into an engineer's position, they're going to have a completely different perspective on things. And the challenge, of course, is that, especially with small to mid-sized companies, you have to start moving quickly. But you can also move too quickly if you just make snap judgments and say, all right, this is what I'm hearing. I'm going to make a decision.
you're likely to sort of get the wrong signal and make the wrong moves. So it was a bit of a balancing act of sort of taking in all this input, but also taking the time to really assess what's going on to come up with a plan. there was one set of perspectives that said, well, maybe we don't have the best engineering team. Maybe we don't have the right engineers. From what little I saw, I didn't think that was the actual problem.
Sure there was room for growth, sure there was room for improvement, sure we would probably have a different engineering team within a year. But I didn't think that was the immediate problem. And the more I dug in, the more I saw it was actually more a problem of leadership and some cultural issues that were longstanding and historical.
that were more the problem than just people's ability to execute. So what I focused on initially was how do I address the leadership issues? Some things I wasn't going to be able to address right away, but the one thing that I could address immediately was getting decisions made. That's where a lot of things seem to be held up.
People weren't making decisions. People didn't feel empowered to make decisions. So as to start, I just made decisions from you like, we're going to do this. What are the two options? Okay, we're going with that one just to get the ball moving. And then every time I did that, I would actually talk to the person who I thought had the autonomy to make the decision and say, you didn't need me to make that decision for you. You could have done this yourself.
And it was just that constant repetition of saying, I'm expecting you to do these things. I'm expecting to make these decisions. I'm expecting to own these areas is what started the transformation because that led into the reorg that we had later that summer, which was all.
about ownership. We had a very functional breakdown of, you know, front end and back end, and that just led to a whole lot of communication issues and sort of the who's on first, what's that second behavior when you come down and get something done. And I was like, no, no. These are going to be the teams. They're going to be full stack teams. And here's the initial set of things each team is going to own. And sure, there's some stuff missing. There are gaps. We don't care. Let's start here.
By shifting the mindset and reminding people that they do own certain things and that are the drivers. I actually recall a sub story of this is going to one team who owned our core playback engine and they were. concerned that an engineer on another team might have feelings about changes they made because he originally wrote the audio engine. I was like, that's great, but he's not on your team and your team owns it. So feel free to propose whatever changes you want. You don't have to be held up.
by this one individual. And that, like, unlocks something and then I'm like, oh, wait, he really means it. We do own this stuff. So within eight months, I'd say, you know, we sort of revisited where engineering was and we went from being
fairly stagnant, not shipping a lot of features to shipping a ton of features. And we didn't change the actual engineers, like maybe one or two people left in that timeframe, but the majority of the engineering team was the same. We just changed how we were leading, how we were making decisions. And that alone made a huge shift in what we were doing. That energizes me for a couple different reasons. I think when oftentimes people think about a transformation, I think...
The stereotypical or cliche view is like probably big, messy reorg, right? To me, it's like, oh, it's painful in motion and people are moving around and it's crazy. And here, what you're talking about is it's almost just controlling the decision makers and... reminding people that they have power and agency and driving this. And then that changes their frame of mind, it changes their actions, it changes how they communicate. And so I'm just blown away by the elegance of the solution there.
Well, simplicity is definitely a hallmark of many of the solutions I come up with. What's the simplest thing we can do here? But even with the reorg, and you're right, with a lot of reorgs, people are fearful of them because it's a lot of change. Sometimes they're just not properly executed. The one thing we focused on explicitly with that reorg was trying to get buy-in with folks.
explaining the why behind the decisions we laid out. Here are the people that are going to be on those teams. We talked to the team themselves and said, look, this is the reason why we're putting you on this team. But at the same time, we also try to remind folks that nothing is written in stone. We're making a change to start to get things moving, but that doesn't mean like you're going to be on this team that maybe you didn't want to be on forever.
It's just the right thing at this point in time. And we will periodically revisit things and see, is this working? Is it not working? And if it's not working, we change it. But I think people have gotten into a mindset where they think once a decision is made, that's it. and there's no flexibility and that too is a hallmark of poor leadership that we don't communicate to people that these things are fluid our needs change the business needs change and that's what
leads to some of these other changes. And sure, there are things like change fatigue. You can do too much change at one time. You can do really big changes that are really impactful. So you have to be thoughtful about how you roll out processes like rewards and make sure that you're communicating. the things you need to communicate and making sure people understand the why behind these decisions.
I just can't tell you how excited I get when sort of the TLDR is when you focus on buy-in, communication, clear decision-making, and leadership. It unlocks speed. It unlocks the shipping of new features in an overall better environment. And I think the clarity of that in the story is...
is so powerful. I want to ask you a follow up question about problem identification and getting to the root cause or this topic of sorting noise from signal. How did you get to that determination that it was a leadership problem versus the inputs of some of these other places like Were there certain signs or signals or things that really helped build your perspective on what might be the case?
There are always patterns. So you look for the patterns. Again, it's that talking to everybody at every level. So you're always going to get different parts of the story. Someone once told me that there are three sides to every story. The first person side, the second person side, and the truth lies somewhere in between. So I use that to sort of triangulate things like getting the top-down view from managers, leaders in the company, what their thoughts were.
than talking to the managers themselves and sort of getting their perspective. But then you go talk to the teams and you get a completely different set of perspectives. Nobody's really going to throw people under the bus. In fact, I wish people were more direct sometimes because sometimes you have to pull things out. But you sort of got a sense of either people waiting to be told what to do about a particular situation. There was a huge theme of that.
And then an underlying theme, especially with the engineers, of thinking that a particular course of action was wrong, but feeling like they couldn't really say anything about it because leadership. said to do X, Y, or Z. Getting some of those signals is like, hmm, okay, we have a combination of what I feel is learned helplessness when you get a lot of the waiting for someone like...
whether it's your manager or your product manager, to tell you what to do. And then that sense of people feel like they can't give their input or just voice their disagreement about something because they've sort of been conditioned to just sort of do as they were told.
And between that and all the historical background that I was getting from a bunch of folks pretty much said, this is how they've been conditioned to behave from previous leaders. And that's the thing we're going to have to change. You said you were talking to sort of stakeholders from different levels of the organization and helping come to this.
When you're in conversation with people saying, here's what I'm noticing and here's what I'm observing. I think this is the issue. One, how is that received? And how do you make that argument and showcase like leadership? Is it the challenge versus like team structure or?
tooling, I don't know, whatever, whatever other people attributed to maybe the challenges, like how do you how do you build and show that case that that this is this is the pathway and we can change some things really subtly to really make impact here. The answer is directly. We have regular exec offsites where we're talking about different aspects of the business. And at my very first one, I gave an initial assessment of like, here's what I'm seeing.
And I pointed out certain patterns. One of the first things I pointed out was the disparity in our leveling, that we had a very high number of super senior engineers, very few early stage and middle stage engineers. and like something about this curve is off and i showed an equivalent ones from uber i think around circa 2002 and they had exactly the same problems i'm like this is what a good curve looks like we are way skewed and i then dug deep into like our top
level engineers and saying, we have a leveling problem. I can tell that these engineers are not at the right level. In fact, they're overleveled and we have a pattern of that. And I said, here are the sorts of things that we would need to do to address that. But then I also didn't make it sort of like a monthly topic of discussion. I came up with a plan of what am I going to do to address this and start doing it?
And the leveling thing was going to take a long time, so I wasn't going to tackle that first. But definitely the learned helplessness and team ownership issues were something I could address almost immediately. And my simple thought process was show, don't tell.
Let's not argue whether these people are good enough or not good enough. Let's change some things and see what happens. And we started by changing some of the decision making. Boom, boom, boom. Features start shipping. All right, we changed who's on which team. Okay, so more features start shipping.
So by the end of the year, when we got to the last offset of the year, it's like, okay, here's what's changed since that first meeting. And they're like, okay, well, what do we do? What's different? Well, we didn't change the people, but we did change how they were being led.
That was basically sort of the proof of concept for the reorg to basically say, we made these changes here. Here's what's resulted from it in this timeframe. And people couldn't argue with the results. It's like, holy crap, we're like making massive changes.
Related to this, some of the changes tied into things the business cares about, like NPS scores. We pay very close attention to our NPS scores. We had a lot of detractors in certain areas of technology. Those scores changed over that time frame as well.
That's really the key for me is that you can talk about a problem all you want. You can come up with hypotheses and propose solutions, but you have to show it. And the quicker you get to problem identification, showing some progress towards a solution, that gets to the buy. that you need at the higher levels of the organization.
Is it really just as simple as having the conversation of I thought you had the authority to make this decision like I expect you to make those decisions and to reinforce that and like overcome the conditioning maybe that was overriding that like is it really just that simple or are there maybe other little
nuances and things at play. The identification of that particular problem is that simple. Sometimes it's literally no one's making a decision. Now, getting people to own the fact that they do own the decision they make, that's going to vary with the individual. I'm not going to say I just got all my managers done and said, you are empowered to make these decisions. Go forth and do so. It never happens that way. There's lots of repeated one-on-ones like, okay, we've talked about this.
And all the different forms of how do you tell people that they have ownership of something? I know a standard one is don't make your problems my problems or don't come to me with problems, come to me with solutions. Those are very pithy, snappy.
things but they do have some truth to it and I do try to break that down for folks like when I say don't make your problems my problems doesn't mean that I don't want you to ever come to me with problems but I want you to understand what problems are actually your problems like they are the things that are within you in your space
And you can decide. You don't need to get my approval or vet. Sometimes I will say, like, why are you even coming to me with this? Or better yet, when someone comes to me with a particular problem, like, all right, what solution would you go with? Nine times out of 10, you're perfectly right. So you don't need me to tell you that, but people need to be reassured because they're either afraid of failing, they're afraid of being wrong.
And they keep forgetting, I'm human just like they are. I'm going to make mistakes. I'm going to be wrong. So why do you think I'm so infallible that you can come to me every time and I will give you the right answer? I'll probably give you a worse answer than the one you had.
You just have to find those examples and those moments to point out to them like, OK, you knew what to do. Why don't you do it? And then after some repetition, people like, oh, yeah, I could just do this. And so some people get that sooner. Some people take a little longer, but it eventually clicks.
Yeah, well, what occurs to me as you're sharing these stories and examples is like from the realm of coaching in the realm of culture change, it's spotlighting that as a blind spot or then reinforcing sort of the type of behavior or norms that you want within the culture. And so what I'm thinking about it.
It's like it's the behavior of a coach is like once you've sort of established like here's the challenge is like helping them reinforce and build that skill or capacity, maybe if it hasn't been normal. Absolutely. Are there other distinctions that sort of signal this idea of learned helplessness in an organization? And maybe are there different ways other than what we've discussed so far that can help override that pattern?
So, from my experience, learned helplessness is often rooted in fear. It's almost always rooted in fear. It's, I tried to do a thing once and I got yelled at for it, or... We broke production and we were all called on the carpet for it. Like there's always some punitive action that's tied to people's subsequent behaviors that exhibit as learned helplessness. And that's, again, totally understandable.
And it's a completely human thing to do. And at the same time, it's debilitating, right? Like if you have to wait for someone else to give you permission to do something, at some point you're going to question, oh, Am I even good at what I do anymore? Like, do I know what I'm doing? Do I have confidence? And that's really debilitating. So I try to point out those areas where folks are leaning too much into learned helplessness and just sort of question.
Again, a lot of it was rooted from poor leadership earlier on that just built a layer of fear around making decisions that only a certain subset of people were in a position to do. I've heard really troubling stories from some of the folks there of like literally being told.
do not do this or wait until this person tells you exactly how to do it. I'm like, these are highly paid engineers. I feel like we're doing the business a disservice. We're just having them sit around like automata's waiting to be given instructions to just start typing.
They can do more than that. But it is a common pattern. I've seen it in company after company. Something negative happens and then people basically say, OK, well, I don't want to be yelled at anymore or I don't want to get a bad review anymore. So I'm going to wait until this other person who.
Maybe there's a power dynamic issue. Maybe they're higher up on the food chain than me. If they say that I'm absolved from anything that could potentially go wrong, now have an organization of tens or hundreds of people that are all thinking that way.
what are you going to end up with, right? Like, why would you want to even work in that type of environment? So learned helplessness to me is like one of the biggest cancers in an organization, and I just want to root it out every time I see it. So I've got a scenario here. Hypothetically, you're listening to this and you realize, oh gosh, that's me.
I am the manager or the leader who has created this environment of fear where the people around me now are hands off being like, well, you know, I don't want to suffer or experience this type of pain anymore. So I'm just going to sit back. And you've realized you're the cause of that. Do you have any advice for somebody who has identified that, who's listening right now? It's never too late to change.
Now, of course, you can't change overnight and just say, okay, no, I'm going to stop doing those things and let them do whatever they want. Your job as a leader is not to be completely hands-on or completely hands-off. You're there to guide, to provide insight, provide direction. If you feel that you may have been too controlling, too dictatorial, start figuring out what causes you to behave that way and start pulling back. Like, is it that you don't trust your people? Well...
Why? Why don't you trust them? For some managers, especially those who are still first line and maybe came from engineering, it's because you used to do the work yourself and maybe you have too strong opinions about how stuff should be done and you should revisit that.
Is the thing that, say, your engineer is proposing right or wrong versus is it the way you would do it versus the way they're doing it? And that's advice I give to my managers all the time. You're going to come to me with a bunch of different solutions to problems. I'm first looking at...
Do you think the solution is even remotely valid? If it is, now the next level is, is it the way I would do it? And as a manager now, that's less important. It's like you're doing it a different way, but it's still valid. Great. Guess what? Do it your way.
If it's different, but there are problems with it, then yeah, it's my responsibility to help you see what some of those problems are. If it's outright wrong, I'm going to tell you it's wrong. And those cases are so few and far between. Those are the situations where...
I've done what you're trying to do. I know what you're proposing is never going to work. And I don't have the time or ability to let you fail at it for you to realize it. So that would be the only time that I'd jump in and be like, no, we're not doing that.
If it's something where I'm like, okay, the only way you're going to understand that this is not going to work is for you to do it and fail. I'll probably let you do that too, because you have to feel like you own the solution. You have to feel like you were able to make a decision and it's not just coming down from me.
And those are the types of things I try to coach leaders on, like look at things from those perspectives and realize where do you have to step in and be the decider? In other cases, where do you have to let things breathe? You get more comfortable with it over time. Well, I think our next topic is going to be a real powerful opportunity to pull yourself out of...
maybe being the contributor to a fearful environment, and now an opportunity to inspire towards a vision. The next side of this, which I think is really powerful. So, you know, we're just talking about transformation and all of the elements that help us shift there.
And the other side of this is the inspirational leadership side. So aligning teams towards an aspirational vision. And I think what's so special with your journey with Splice is a vision like augmenting creativity, which is something that is so big. And there's so many pathways to achieve that. And then how do you bring everybody together around that and connect that from the top to the bottom for every role?
I guess maybe bring us in a little bit of context around Splice and your journey there, and then let's dive into this topic of aligning people around a vision, and especially one with this high, aspirational, big quality. That's motivating the company. Bring us in, bring us in a little bit more into the context. I recently celebrated my two year anniversary at Splice. So two years ago, I was making decisions about my career path. And there's this opportunity at Splice that several people I knew.
clued me in on. I was having drinks with a friend from Adobe who I believe they were trying to recruit for the position, but he just accepted another one. But he said, you should talk to Kevin Stewart. He'd be perfect for this. At the same time, The interim head of engineering at Splice was also a former co-worker from Adobe. And when he heard my name, I was just like, oh yeah, Kevin. So he told the CEO about me. And then...
I knew one of the founders of Splice before he founded Splice. So I think when he heard my name come up, he's like, yeah, you should talk. So all these people who knew me had some connection to Splice and they're like saying. We got to talk to you. So one, even though I'm not a superstitious or religious person, when the universe is giving you signs, you just sort of go with it. So I met with the CEO. She and I connected pretty quickly. This was like.
towards the end of the year during the holidays. So I found myself right before Christmas having a ton of interviews, then getting reference checked, like day before New Year's Eve, on Christmas Eve. The more I was talking to People's Place, I was getting excited about the opportunity. They seem to be getting excited, so I made the leap. That said...
I am an appreciator of music. I am not a creator of music. I couldn't create music if I tried. There's maybe a sordid part of my high school history where I might have done talent shows and sung in R&B groups. But this is pre-internet, so nobody's going to find me. out about that ever. But that's about as much that I could contribute to the musical zeitgeist. And from there, I've been just really getting engaged with the mission at Splice, which is to empower music creators everywhere.
And part of that resonates with me because, again, I was a software engineer, so there are similarities to the process, to things that people care about. So I found my way to connect with the mission at that level. A lot of the engineers, a lot of the people at Splice are musicians. They are DJs, they're producers, songwriters, vocalists. So we have a lot of people that represent our customers working at Splice all the time, and I'm constantly amazed.
at the talent and creativity these people have. So they bring that into their work. And to me, that's the most powerful thing because if you can tap into people's intrinsic motivations, that's how you... connect them to the bigger vision and help drive things forward. Well, and I think, you know, as you've gotten involved in Spice, like there's a really interesting A-B test of vision and the impact of vision on strategy and execution.
And so I was wondering if you could bring us into the story of, you know, maybe the initial strategy rollout at Splice that you were involved with, and maybe some of the challenges that happened with that, the things that you learned. And then, you know, the B test, what was then introduced that really unlocked a lot of things at the organization?
So I'd probably say towards the end of 2023, we were starting to work on strategy for the company because we didn't really have one at the time. So you had a brand new executive team, a lot of folks really. trying to figure out the path forward for supplies and at the end of the day what we came up with was fine it was good it gave us some okrs gave us direction the challenge was that much of the strategy was
framed in terms of the business needs and not as much in terms of our customers. And I think that's where, as we started to execute against the strategy, we ran into some of the headwinds of how we'd framed everything in terms of the people day to day trying to do the work, not really seeing how does this connect? Like it's one thing to say, hey, we want to get X new new subscribers. Great. That's a real tangible goal.
But then without more of the framing and the context about how is this helping customers and how does my work connect to that? People were just given sort of that one financial goal and tried to connect everything they were doing to that. Like everything I do must connect to getting new subscribers, whether it did or didn't. That created some impedance mismatches along the way with how we were executing.
I'd say halfway through last year, we sort of, one, saw that we weren't tracking as well as we should have been to our OKRs. But more importantly, we were getting all this feedback from folks of like either being confused or not sure what the prioritization should be.
So that sort of fed into the end of last year, prepping the strategy and taking all that into account, we all sort of collectively realized, okay, like one, some of these metrics were probably the wrong metrics to really drive towards. But more importantly, it's like there isn't a North Star for our people, especially in product development, to really understand why are we doing these things for the customer in addition to for the business. And that's where a lot of the focus was at.
in terms of really defining that strategy, which led also to us making a fairly big shift in what we were pursuing going forward. in terms of the more content-oriented business that Splice is, with being the largest provider of royalty-free samples, if you're going to empower music creators everywhere, it's really more about the tools and their workflows.
how they retain the joy of making music, but become way more inspired and way more effective in the process of creating music. And that's what really drove the definition of the vision. But more importantly, and again, I take it. no credit for any of this because i was blown away by this as well one of our designers created a concept video that encapsulated the vision and presented a north star for everyone to sort of see like it's not going to exactly look like this
But this is the sort of effect we want to have on our customers when they're able to use our tools. And every time we show that video internally, externally.
One, you just can't stop bopping your head because the music's great. Shout out to Mike, our designer who did it. As it should be. But you really... can see yourself in that position to, you know, just making a beat and then finding vocals and finding complimentary sounds and tying it all together and making it so seamless and buttery smooth.
that you want those tools, you want that ability. And that vision video by itself was the primary tool that we used at the end of the quarter that we just walked every team through and said, hey, this is what we're trying to accomplish with the strategy.
And we did a presentation and sort of walked through all the outcomes that we were trying to achieve and some of the opportunities we were going to chase. But we ended with that video, and that brought it all home for everybody. And every time he showed it, you could see. The eyes lighting up, the people getting excited, and that's when you know you got them. Now we just play the video all the time to sort of remind them, like, this is what we're going for.
and they get excited and you know right now we're still in q1 but folks have been working on prototypes and features that drive towards that idealized goal the north star that we're shooting for And you can still feel that excitement when they're presenting their work, when they're showing their demo. We just had a monthly check-in this week where we saw from all the teams what they're working on.
And you can see that the goal is actually attainable, like we're making progress to it. And that just reinforces the excitement with us, creates like a positive feedback loop. You give them something really hard to attain, but then you start showing progress towards that and people are like, hey, this could really happen. This is going to happen. Let's keep doing. Let's keep going. Tapping into that intrinsic motivation and then feeding back in, that's how it works.
The reason why I love this moment so much, because I'm, you know, putting myself to somebody who's listening to this, who's like, how do I align my team? Like we have, as our business, this big lofty goal. It's aligned with, you know, their version of augmenting creativity. First off, the emotion, the clarity of what this could look like, and just like the visceral sense of as somebody who maybe who is a creator in that space, who's watching this within your team, like...
wow, like the power of that. Because then now all of a sudden you have this mission to contribute to. And you can start to, as you're saying, like now these demos, you start to see the pieces and how they all fit together to bring this to life.
Is there a specific moment where you saw the tide shift and you were like, this is it. The power of the vision is expanding. We can see it. I wouldn't say there was one moment, but there were several moments. The initial showing of that video to the different tangents was one moment.
The other moment, and probably the more important moments, were showing people inside the company either user testing sessions or videos with other famous musicians and producers using the tools and their reactions to it.
It's one thing for us to just promote something internally, but when you actually get things into the hands of actual customers or potential customers and you see their genuine reactions to the things that they're doing, that's when it hits. That's when people get excited when they see.
a well-known producer using your stuff and like totally geeking out on it and giving real genuine emotions about that. So I think the combination of just, again, their own internal connection to the work, but then seeing it in the hands of others that they respect, or at least. recognize that one-two punch sort of said, all right, we're on the right track. We're going to make this happen.
Are there other insights or takeaways from this vision realignment that you might recommend other folks to consider in terms of if they feel like they're experiencing a similar stuckness or maybe lack of connection to the vision, here are some things to consider.
Not something that came out of this particular process, but something I've learned along the way. Repetition is key. Like you can't be one and done. Like, here's our big vision. Remember it. Have it stick with you. You got to keep reinforcing the message over and over again. Sometimes. It takes a while for people to actually hear what you're saying. They may be further away, say, from customer work, but then as things develop, they're like, oh, now I get it. Now I see.
So that repetition is key. Similar, frankly, to key aspects of remote leadership, which I also have to deal with, is it helps to have real-life connection with people periodically. You're remote, you're behind a Zoom screen. You're reading a PR on GitHub and you're like, wow, this guy's a jerk. But then you're like, no, no. I remember we had dinner at that Mexican restaurant at the offsite. He was great. It was hilarious. That reinforcing of connections of like.
This person that I only deal with behind the screen and only see every three months is a real person that has a real personality and not just the text I see on screen. Same thing applies to sort of reinforcing a vision. It's like the memory fades a little bit or you lose some of the details. So by repeating it over and over or showing it in a new context, like...
showing it in a customer's hands, showing a new version of the feature that's maybe more fleshed out than what you saw a month ago. Those are the sort of things that just help reinforce the message, reinforce the vision and reignite. those emotions that people originally felt and propel them forward. The next thing I wanted to dive into was, so here we are, we've talked about transformation.
And then from there, we're talking about aligning people around a vision and some of the different ways to drive that. And then the other side of this then is also how you spend your time. And then also how do you expand your team capacity and delegate and extend ownership and... decision making to other people. And so you were sharing with me earlier one one particular story about like the moment where you were determining your concentration of time spent.
This is something that I probably intuitively knew fairly early on, like once I first became a VP and started working at a more strategic level, was that more of my time had to be focused on the business and less on the department. our CEO here at Splice, made it very concrete to her entire leadership team. She's like, my expectation is that you're going to spend about 30% of your time focused on your individual departments and 70% of your time on the business. And I think...
Hearing it that concretely with like numbers, percentages, like this is what I'm expecting of you really make me rethink like, where's my energy going? Where's my time going? I am always pretty organized and, you know, detailed person, a lot of things, but then I like stepped back and looked at my calendar and then got really aggressive. Like, here's how much time I'm going to dedicate to one-on-ones with folks. Here's how much time I'm going to dedicate to.
Paying attention to the details of a project, because at heart, I'm still an engineer. I like reading RFCs to see, read the technical details of what people are doing. It keeps me sane, but I'm like, I can't be in the weeds all the time.
I can read an RFC and I can comment on it. And that's like, that's the line. Like that's almost entertainment for me after a day's work is I could go read an RFC and it's like, ooh, what are they using over there? But that's it. I don't go like into the linear project and... Pay attention to every last little detail or weigh in on everything.
I don't have the time for it, and frankly, I shouldn't be doing that sort of stuff. That's what my first line manager's for, or even my second line of managers are for. But I spend now more time with my counterpart and product.
I spend more time looking at our business metrics and trying to figure out how are we going to achieve that particular revenue goal. I spend more time in spreadsheets than I do in Visual Studio Code. In fact, There's a part of me that aches that I haven't fired up VS Code in God knows how long at this point, because that's not where my attention needs to be for the success of the business anymore.
Now, to do that, you have to be able to delegate. You have to have people that you trust to run the department for you. That's 70% of the time that you're not paying attention to it. And luckily, I was able to bring in two folks onto my team that I've worked with before and worked with me twice before. So they're literally my right hand to my left hand. And I know that I can give them anything. They will take care of it.
When they need me, they'll come and seat me out and say, hey, we need your help on something. And I'm using them to help grow the other managers in the org as well. It's like, I want to get. all of them up to that level of trust and competence to be able to do things. I still pay attention. I read everybody's weekly status reports. I jump in on product reviews and solution reviews to sort of see where things are going.
I see myself more as a curator or an editor now, more so than like a beat writer. I'm not the one writing the story. I'm just reviewing the grammar or saying, hey, this isn't going to have the impact that you think it's going to have. And that's more my role now.
Two different elements I want to explore here. First one, you talked about aggressively looking at your calendar. Walk us through how you approached auditing your calendar. What did it look like to assess your time? And what were you looking for to curate and edit the calendar? First, I wanted a plan of how regularly I'm going to meet with people based on what it is I need to do. So I actually created a Google Doc where I just had sections weekly, bi-weekly, monthly, quarterly.
And it's like, okay, all my direct reports, meeting with you weekly. I'm having a staff meeting weekly. their skip levels okay some of those are going to be bi-weekly some of those are going to be monthly and i just started bucketing everything based on how much time should i spend on this particular thing and yeah some people would love me to spend more time with them like
I can't. So I have to really decide like, what am I getting out of this? And what am I going to be able to provide in that time that's going to be valuable to have it at this cadence versus this cadence. And that was really the deciding factor.
There's some things I don't have a choice on. Like if my boss wants to meet with me, guess what? I'm meeting with her. And in fact, there's a point where we try to like carve out a day of the week, like most places do, like no meeting Tuesdays. And for a while, I managed to keep that going pretty well.
But there's always something. So as I got a new EA, I told her, I was like, all right, these are supposed to be no meeting Tuesdays, but here are all the exceptions that are allowed for that. Like if I have to interview a candidate and that's the only time, yes, you can.
overflow that. If we have to have an exec meeting, yes, you can follow. If the CEO wants to talk to me, of course, but it was intentional. And I think that's the key. You have to be intentional with where you're spending your time.
I really love the rules and the intentionality there. I mean, I was telling you, I'm reading the book about 4,000 weeks. So I'm like, yeah, choosing how you want to spend your time is incredible. And the types of problems you want to focus on versus like just getting through the thing.
The other side of this is, like, how do you help your team make that shift so that they're operating the department in a higher concentration? Like, what does that shift look like to support and power so that the majority of that's operating with them as the head? The first step was actually sharing that expectation with them. Like we had a staff meeting and I said, here's how my leadership wants me to spend my time. So by definition, that means I need you guys to do this.
We just had the conversation, like, here's what I'm going to be spending my time on, and here's what I'm going to be expecting you to be doing in the time frame. Some of them were looking for that, like, if you need us to do that, great, we'll do that. We'll take that off your plate, which is exactly what I want to hear.
Great. Thank you. Take care of that for me. My reports especially are really good almost every week saying, is there anything that you need us to do? Is there anything that we can take off your hands? I'm so appreciative of that because I'm like, yes, if you can take this off my hands, that means that now I have time for this other thing that I wasn't quite sure what I was going to squeeze in. Again, the repetition of every week when our staff meeting starts, I start with.
giving them some insights from the exact team of here's the things that are going on. Here are the things that are on my mind. And then they can read into that and say, okay, well, if you're dealing with that, again, what can we do to support you? And you build a relationship of supporting each other. I'll ask them, what can I take off your plate? Or what battle do you need my help fighting that you can't do on your own? They'll look and subsequently say, hey.
What things do you need us to do so you can go do the things you need to do? And that's a healthy relationship. What a fun full circle of leadership going back to, you know, the transformation part of it is like clear expectations, clarity of decision making, and then full circle when you're thinking about expanding capacity of the organization.
and shifting the way that you spend your time and empowering your leaders to take on more, it's clear expectations and then also the bidirectional expectation sharing and shifting. Because I'm also thinking of like, what an expansion of their leadership.
When you say like, here's where I need to spend time, I need you to take on more. Like for somebody who wants to grow as a leader, like that's a big expansion moment. Yeah, they're all doing fantastic. One report had just gotten promoted to a senior manager right before I started. Helping him grow is like my pet project because, one, he's just a delightful human. Everybody loves him. Just genuine, warm, kind, and a fantastic leader. And we actually had a 101 this week where...
We talked about like, do you want to go broad or do you want to go deep? And he's like, within five years, I really do want to be like at a director level capacity. And I'm like, my mission is to get you there. I'm going to get you there. One of the people I brought in, she, again, fantastic leader. I had the pleasure of promoting her this week to director because she killed it last year on every level. My other report is a senior director.
amount of work he's put in to help level up some of our engineers that were frankly rudderless for quite a bit and now are executing really well. The technical leadership that he brings to bear, like we've been friends for 20 years.
And I'm still jealous and in awe of his capacity at some times to just like be able to tackle the most complex problems. And people are seeing that. And the person I'm looking to grow over the next five years, he's kind of fanboying over this guy in a good way because. he realizes there's so much he can learn from him. So just having that to work with on a day-to-day basis is like being a kid in a candy store.
In my head, what I'm imagining is sort of this storybook of leadership and closing the page and being like, the end. This is the hard-fought, happy path of the giant quest. I mean, we were talking at the beginning of transformation, vision, you know, expanding capacity and delegating.
To hear the recognition of folks on the other side of this, knowing the hard conversations, the behavior changes, the cultural shifts, the operating norms that change, like it's just really powerful to sort of have this full closure moment.
to hear the impact that this has had on people on your team. Yeah. But of course, the story never truly ends. You can never really close the book. That's just volume one. Got to go on to volume two. That's right. Well, Kevin, we've got some rapid fire questions if you're ready to jump in.
Oh, let's go for it. All right. All right. All right. So first question, what are you reading or listening to right now? I'm probably listening to way too much Kendrick Lamar right now, especially after the halftime show. But I'm reading the NVIDIA way by Tay Kim, especially with all that's going on in AI and NVIDIA's role in that right now. I saw this pop up in Amazon. I was like, I know of NVIDIA, but I don't really know it. So learning the sort of origin story there, I think is.
Definitely going to be useful. So hopefully be able to make more ground on that book this weekend. But that's what's currently on my Kindle right now. That's great. Next question. What is a tool or methodology that's had a big impact on you? So while I am totally against what Agile has become at this point, back in the day when Pivotal Tracker first came out, I love that tool because it exuded both simplicity and an opinion.
Like it wasn't Jira. It wasn't any of these tools that try to be Swiss Army chainsaws and do everything. It's like, this is the way it works. This is all we do. And actually, when we were working on Creative Cloud at Adobe, that's what I was using as my project management tool. It became an extension of me because it was just so straightforward, so simple, allowed me to do what I needed to do.
And I didn't have to think about it. And I think that's sort of a lost art in software design now of really being focused on what is the essential task and not trying to do everything for everybody. So yeah, Pitbull Tracker definitely sticks in my head of all the tools I've used and I've used so many. All right, next question. What is a trend that you're seeing or following that's been interesting or hasn't hit the mainstream yet?
As much as you do hear about AI coding tools, I don't think it's mainstream. There are different classes of developers, and there are the folks that are totally in the startup environment. are building greenfield projects, they are more likely to be using a lot of AI coding tools than, say, enterprise developers.
And sure, they are making some penetration there, but to me, that's more the mainstream. And I think related to that is there's still a discussion to be had about the best use of these tools. currently struggling with this ourselves, like we have junior developers who want to use those types of tools because they believe they'll learn faster and better with them, which there is some truth to that.
At the same time, they're junior developers for a reason, right? They haven't yet developed certain skills that you can see becoming easy for them to assume the AI tools solve those problems for them. And the pushback I've given is, okay, great that you use an LLM to generate this code and it looks right to you, but then it doesn't work in the context of the system you're building it for. Like the LLM doesn't know about all these other variables that maybe come into play.
So now when we have an outage at 2 a.m. and people are trying to figure out, well, what's going wrong? But they don't know because they only worked on that feature that the LLM generated on. They don't understand the context of the bigger system. And oh, yeah, by the way. They haven't really developed debugging skills yet because they're relying on tools to do everything. Like those are the bigger problems I'm really worried about. And at the same time.
We can't ignore the fact that this is probably the way the industry is headed. So we do have to start thinking about, for the mainstream, how do we want to grow junior developers in the context of these tools becoming the norm? what happens when our senior developers age out, retire, change industries, and you just have the tools and not as well trained senior developers anymore. Where do we go at that point? And you can't blame the tool afterwards saying, well, the tool generated the code.
Okay, great. And as you lose revenue and your boss is screaming at you, what's that going to get you? For as much hype as there is around the cursors and windsurf and all the co-pilots that exist, I don't think it's mainstream yet. I think it will be, but we also have to address everything that comes along with it. Last question, Kevin. Is there a quote or mantra you live by or a quote that's been resonating with you right now? Yes, because I've actually been using this quote to kick off.
interviews that I've been having for a director of engineering candidate. If you want to build a ship, don't drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea.
And then I asked them, can you describe a scenario where you've embodied the sentiment in your own leadership? And the thing is, like so many of his quotes, this sort of resonates at a very deep level with me and comes back to how do we inspire and connect people to the vision?
It's not by coming down from the mountain with two stone tablets and saying, build these things. It's painting the picture and tapping into that intrinsic motivation to get people to want to get to that North Star. And as you share that, I reflect back on the concept video. That is the ship and that is the yearning for the sea moment for Splice. And it's such a powerful moment. Kevin, thank you so much for an incredible conversation about the heart of leadership.
the transformation, the building of vision, the expanding impact and delegating and stewarding your time. This has been a ton of fun. Patrick, it's always fun talking with you. Thanks for having me. And let's do it again sometime.
If you're listening to this and you're wondering, how can I connect with other engineering leaders in my city? Pull up your phone right now and go to elc.community. Click our chapters page. You can see that on the menu on the left. Find your local chapter and click join.
We're hosting virtual and in-person events all the time, and this is the best way to help you get involved, expand your network in your city, and support your leadership and career growth. So pull up your phone, head to elc.community, join your local chapter, and get involved. Huge thank you to all of our local leaders who make community happen. And thank you for listening to the Engineering Leadership Podcast.