Kevin Goldsmith

The human problems were actually more interesting…the biggest differences between teams that were successful and teams that weren’t wasn’t that they were just smarter technically, it was that they worked well together.

How do you lead a high-performing, empowered team? Kevin Goldsmith, a former Adobe and Spotify leader, joins the Humanizing Work Show to share his journey from engineering to executive leadership. We explore his take on the Spotify Model, how he approaches mentoring new managers, and why positional authority matters more than most leaders realize. Perfect for anyone in tech, leadership, or agile, this episode offers a fresh perspective on building sustainable, people-centered organizations.

Show Notes

Contact Us

📧 Share a challenge or episode idea: mailbag@humanizingwork.com

Connect with Humanizing Work:

Episode Transcription

Peter Green

Welcome to the Humanizing Work Show! In today’s episode, I talk with Kevin Goldsmith, a longtime friend and seasoned tech executive. Kevin shares what he learned from early roles at IBM and Microsoft, his leadership roles at Adobe and Spotify, and how today, he helps scale effective engineering leadership as an executive and advisor.

Kevin gives insights into how the shift to agile in the early 2000s shaped his approach to leadership—and he shares powerful examples from his time at Spotify, where he experienced firsthand what’s now famously known as the ‘Spotify Model.’ But as Kevin points out, many organizations get this model wrong. He’ll explain why, and what the real principles behind it look like.

Throughout the episode, Kevin dives into the human side of leadership—why it’s more often important than the technical side. He talks about the art of building cross-functional teams, the nuances of ‘servant leadership,’ and how to create autonomy within a team while still providing guidance and accountability.

And if you’re an engineering manager looking to step up, Kevin has advice for you too. He explains why new leaders need to find that balance between direction and support and how understanding your positional authority can make all the difference.

Whether you’re a seasoned executive, managing a team, or simply interested in the way agile and leadership intersect, you’ll find Kevin’s perspectives both insightful and practical.

The Humanizing Work show is a free resource sponsored by the Humanizing Work company, where we help organizations get better at leadership, product management, and collaboration. Visit the contact page on our website, humanizingwork.com, and schedule a conversation with us if your organization wants to see stronger results in these areas.

If you want to support the show, the best thing you can do if you’re watching on YouTube is subscribe, like this episode, and click the bell icon to get notified of new episodes. Drop us a comment with your thoughts on today’s interview with Kevin. And, if you’re listening to the podcast, a five-star review makes a big difference in whether other people find it or not.

Ok, let’s dive into our interview with Kevin Goldsmith. Welcome, Kevin, to the humanizing work show.  Great to see you again.

Kevin Goldsmith

Yeah, great to see you.

Peter

Maybe you could give us a little bit of your background on your first roles in engineering before you got into engineering management, and specifically, what are some experiences you had then that sort of shaped how you see managing teams now when you were on a team?

Kevin

Okay. That’s good. I got to dial sort of the Wayback machine pretty far back, unfortunately. So, I first started as a developer when I was still in college. I started working for IBM, back in 1991. I was primarily serving multimedia type person, and I worked on, like, early, early streaming media stuff at IBM research.

And then I went more into graphics. I was doing graphics stuff, moved to the Valley, to work for Silicon Graphics there, and was doing graphics stuff. I ended up at Microsoft Research, doing graphics stuff, and that’s where I really started to have my kind of first manager roles, like managing an intern and then, you know, being a lead for a small team.

And at Microsoft, I kept kind of going back and forth between sort of lead, and then more like senior engineer, and I was at Microsoft for six years the first time. So, I would kind of spend a couple of years in a role as a lead kind of managing people and then wasn’t really excited about that or was more excited about technical opportunities. So I switched back to being an engineer. I left Microsoft to do start-ups, and that’s where I ended up in my first real kind of management job, where I was now managing like a team. Speaking of agile, that was also where I learned agile. So that was back in 2000 and the XP book had come out and we decided to do XP at my company.

And having just come out of six years of waterfall at Microsoft, that was like, in just seeing the horror of how that worked. I was super open to trying something different. So that’s really where I started my agile journey. Because of the downturn and back at Microsoft again as a developer, did that for a few years and then came to Adobe.

And Adobe’s really where I started—at Adobe– as a kind of senior developer, kind of technical lead, not management. And I was working on this project, where it was being managed by the head of Adobe Research. And it was always going to be temporary. So, we were building up this kind of new technology team.

And so, he always was like, yeah, I’m doing this to get off the ground. And by the time we got to the point of like, actually we need a new manager at that point, just seeing the way Adobe dealt with management, which was to treat it unlike Microsoft. Treat it more like an actual kind of role with support and training; and people there took management as a serious activity as opposed to something you did while you weren’t coding.

And that became–  I met some managers I really respected. And also at that point I had been working for a long time and I was trying to decide sort of where I go in my career and that’s what sort of led me into management. That’s where I sort of– that’s where I made the decision, “I think I want to be on the manager path now.” And so that’s sort of how I ended up there.

Peter

Uh huh. What about the role of manager seemed intriguing to you, because you’ve got such a strong technical background? Especially with your sort of, experience and advocacy for an agile approach, which I experienced when we first met. What about the role of manager made you think, “Yeah, maybe that’s the thing”?

Kevin

I think, one; I acknowledge, like, I was a really crappy manager when I started because I kind of became a manager for the wrong reasons. Either I was pushed into it because I was the most senior dev, or I chose the role. I was offered it and chose it because I really wanted to make sure things were done the way I wanted them done; which was the absolute worst reason, which I didn’t realize at the time, because I didn’t know any better. And like I said, especially when I was at Microsoft, people– that’s kind of how it worked. What I realized when I made that decision, what I’d come to realize, is that while the technical challenges were very interesting to me and still are (like, I’m still a very technical person), I care a lot about that stuff.

The human problems were actually more interesting– have become more interesting. So how do you build an effective team? How do you deliver value to customers faster? Coming back to –I do credit actually becoming more of an agilist, with helping me kind of come to that realization is that the biggest problems I think I’ve seen, like the biggest differences between teams that were successful and teams that weren’t, wasn’t like the teams that were just smarter technically. Of course, that helped, but it was really the teams that worked well together.

Those were the teams that ended up delivering faster and doing a better job. And so I just started to realize, like, that kind of problem started to become a lot more interesting to me. Like, how do you enable people, how do you support people? How do you develop people so that they’re contributing individually well, but then how do you take that group of people and make them effective as a unit instead of a bunch of strong individuals, each doing their own thing?

Peter

Yeah. As you started trying to figure that out, where did you go to learn that? Did you have mentors? Did you have maybe previous managers or other people, peers at Adobe or books or where did you go to try and figure out how to do it?

Kevin

So, one of the things that was challenging, was there wasn’t a lot of resources, right? So, one of the benefits Adobe had was that they had, like, manager courses. And I took every one of them. But it was really about the mechanics of management. It wasn’t really about these things I’m talking about.  So, management literature still kind of sucked. You had like, there’s a, like, a managing agile book I read, that is horrible. But I was reading a lot of agile books. I was reading manager books. Michael Lopp’s first book came out, Managing Humans, which was at the time, you know, pretty revelatory because everything before that was very kind of 80s style, kind of old school; kind of almost factory management type of literature.

But it was really, I think, a lot of the agile literature, because that was also (now you’re talking like mid 2000s into kind of 2010), agile was just exploding at that point. And so I was able to find like a lot more agile literature. You know, in general Weinberg and Juri, and his stuff, but then lots of other places.

And that’s also where you started to see more blogs and things like that, which also I started to just devour. I absolutely found mentors. I think, you know, we had a lot of good conversations. There were other folks, but, you know, I was really assembling it kind of from various pieces on my own, which was okay: But it wasn’t great. I think where I made my last group at Adobe, by the time I left Adobe, I was a director and I had about 4 or 5 (or 6) teams that were all working together on some products, and I was starting to hit the limitation of functional teams working in a unit. And having to pass things back and forth; and starting to experiment within my own team, like, how do we do this better?

How do we do this more effectively? Like we were trying– Lean Startup came out. We were very much taking a lean startup approach with how we delivered the first version of this product, and the one thing that was slowing us down was like having to do all these handoffs between teams, working really closely together. And I hadn’t yet hit on the idea of a cross-functional team like a product team, like a feature team like we have now. But to be honest, like, there wasn’t a lot about that at the time. And that’s right about when Spotify approached me. They were looking for a new tribe lead in Stockholm. And at this point that white paper– the Spotify white paper– had been published, but nobody knew about it.

I hadn’t heard about it yet because it’s only been out for a couple months. But, I was talking to them, I went there, they sent me the white paper. They sent me all their kind of internal stuff on how that Spotify model worked. And I realized they’d solved this problem. They solved the problem I was seeing and trying to deal with.

How do you get a whole bunch of agile teams working together in the most optimal way? But they were also thinking about how does that scale, because they are very much like a hyper scaling type of organization. And I think we saw at Adobe some of the bigger challenges around kind of scaling agile, right? Like we had Scrum of Scrums and all this kind of stuff.

But we still had these kind of fixed points that these coordination kind of sync problems. It was better. It was certainly better than I had at Microsoft. Way better. But it was still–we still had a lot of sync challenges as the organization grew, Spotify had really solved that. And that alone is what convinced me. Like, I have to go work here because I have to see what it’s like to actually live in this world.

And I have to give credit there to that organization, because they were a learning organization, but they were also like a sharing organization. My peers in the kind of senior technology leadership team, like we were all reading, we were all talking, we were all visiting other companies and like sharing ideas like we actually formed like a group with a ton of other companies in Europe where we just go visit each other and then, you know, did, like, temporary transfers where we’d switch people for a little while just to learn, like what cool things they were doing and sure, what cool things we were doing.

So that ended up being like, honestly, like an MBA in how to build scaled agile teams, in a very effective way. So that’s– I learned a lot on my own, but it was really there that, you know, that I found it. And that’s also where I think I got a lot more involved, not just consuming from the agile community, but also participating and speaking at conferences and like meeting, you know, tons and tons of different folks. That helped a lot.

Peter

Have you figured out, sort of, like, here’s the fast track. Now, if you’re going to promote somebody from an individual contributor into a management role, what do you do to help bootstrap them along? Because I think all of us of our generation had to figure it out.

Kevin

Oh yeah.

Peter

And it seems like we’ve learned a few things now. So what do you do to help new managers? I guess accelerate that path to understanding what it really means to manage an empowered team.

Kevin

Within the technology teams, we have a community of managers, right? So (and I very purposefully tried to, one, build that community of practice, but then also very much and like a Patrick Lencioni style, kind of first team, second team kind of mentality where my direct reports,  my first team, is really the executive team).

But you know, I want– I try and very much encourage and support the development of my direct report, becoming their own first team. And so I very consciously kind of build that, but that community is open to generally, definitely all the people who are people managers. But then also we open it up to the people who are considering or interested potentially in becoming a people manager.

So the only thing those people maybe don’t have access to is like when we talk about salaries or we talk about other stuff that involves personal details of employees. But as far as kind of like that might include, like we share readings with each other, we share conference talks with each other, we go to conferences together.

There’s a lot of mentoring, kind of peer to peer, but also obviously I’m mentoring all of them either directly or, you know, on a weekly basis or a monthly basis, you know, because that’s something I never had, right? Really up until Spotify. I think there was a community of managers at Adobe, but it was really like we’re peers kind of working on stuff, but we’re not really talking to each other about the job. Right? I had mentors at Adobe but not really a peer community. [Yeah.] And that was one of the things I just found so valuable when I went to Spotify. It was just this notion of these kind of different communities, guilds for different specialties. But at the management level, we didn’t have manager guilds—we just all talked to each other and would all meet with each other pretty frequently.

Peter

Which sounds like what a guild is. You just didn’t call it one.

Kevin

Yeah, yeah, the management guild wasn’t–Yeah, there was a management guild. We just didn’t call it a guild. Yeah. It was effectively a guild.

Peter

Yeah. Can you give us a little bit of sort of a day-to-day one of these communities in, you know, a company that you’re leading today? What does it look like? Is it, you know, a monthly meeting, is it weekly? Is it a slack channel? Just give us some of the logistics. If somebody wanted to set these up in their own company, how would they do it?

Kevin

So one is we will do kind of meet ups, and we’re fully distributed. So it’s not like we just all, you know, sit in a conference room. It’s we all fly to a place and kind of lock down for a few days. So we’ll do stuff like that. And part of that is always like the last time we did that, we spent a lot of time talking about what is the role of the manager distributed, like what are the skills that we should be each expecting of ourselves and expecting of each other? And then where do we feel like we are on that, against those skills? And that kind of gave me a good map of like, okay, well where should we focus training and things like that. So we’ll do those kinds of sort of meet ups. Then we’ll do, I meet with my directs weekly; with all managers I have at least monthly where I’m directly supporting them. And that is generally like helping them problem solve, but also career development and things like that.

The managers at the next level have their own meeting, where they work together and they talk and they share knowledge with each other. The next level down has their own meeting as well, where they’re very similar. And that one includes, like the agile coaches. So that starts to approach more like, the POCLAC (Product Owner, Chapter Lead & Agile Coach) like with that staff idea, which was the product owner, chapter lead and agile coach, like the folks who are working with the teams day in, day out. They start– that’s where they kind of get into.

But it’s multiple managers. So that’s also where they’ll share stuff. And there is some mentoring in between, but not in a formalized way. It’s really people reaching out. So right now we have somebody that we’re developing into a manager. We have a couple people that are interested in, we take advantage of stuff like, one of the people that’s working her way into– kind of interested in moving into a manager role.

Her manager is out on parental leave right now. Just left on parental leave. So while he’s out, she’s in charge. And we spent some time kind of getting her to that place where she was hopefully ready. And then I’m going to work with her while we’re doing that. So she’s got several months where she’s going to be running the team and sort of experiencing that. But obviously with support from me, to do that; and that, to be honest, has been one of the most effective ways I’ve found to give people a taste of it. But without all the baggage. Right? Because if you just put somebody in charge of a team, you used to be a peer, now you’re in charge, like what happened to you and me– If it doesn’t work out, that’s pretty bad, right? Because you went from peer to boss and now back to peer. And that puts a lot of pressure on the person not to, like, have to do it, have to be successful. But you do it as an interim step either if, you know, the benefit of something like paternity leave, perfect. But if you don’t, you kind of do it as you find some other excuse to, to have them do it as an interim thing. Everyone knows it’s an interim thing. So you kind of avoid some of those kind of things, but they get a real taste for the job. And to be honest, having done this now for like ten years as a way to kind of give people a taste without forcing them into the role, the success rate on that, like people then move on to being managers is about 60%. Like people try it and a lot of people just like that.

Peter

Yeah, it reminds me: So, in the video group at Adobe, they had this role for individual contributors every cycle. While we were doing these big long, you know, two year cycles. But they called it the “feature maven.” The feature maven role was essentially you’re the product owner for the next release. You’re in support of the product manager, who is still sitting on the feature team with you, but you really take the lead.

You organize the meetings, you facilitate them. You sort of have this, like, fancy title with no compensation that goes along with it, but it’s a chance to try it out and see how you like it. And that I was in that feature maven role. The release before I learned about scrum and became a program manager and, you know, adopted scrum on that team and same thing: Like it was just super useful. Either people did it and really took to it or they realized, it’s not for me. Right? And so it was really a great filtering function. It would be interesting to see how those things seemed hard to formalize. Like, Adobe did a good job with that specific one, but there wasn’t the equivalent of like, “I want to try out engineering management,” right?

Kevin

Right. I did do it at Adobe, but it was very much like “I’m officially, but you’re unofficially and everyone’s going to understand this.” You’re going to have one-on-ones with people for sort of this length of time. And everyone understands this or like, you know, you lose a manager on the team and you have somebody step into the role temporarily.

That’s the kind of thing. I like that, just the idea just generally of like giving people a chance to try roles like, you know, it’s a practice in a scrum team to like, alternate who is the scrum master like every sprint or whatever that I’ve seen turn a lot of people from tester or developer or whatever into future agile coaches.

Because they get sort of a sense of understanding the roles a little bit better, and maybe they start getting a little bit more excited about the processes. And then kind of over time, I’ve had quite a number of people, once you start rotating roles like that in an agile team, kind of realize like the agile, that’s the thing they’re excited about, as agile coaches,

Peter

You mentioned when you were talking about the meetups or the offsite that you did, you mentioned this process for doing an assessment. I think you wrote about that. I think it’s—we’ll link to the article. I think that’s really a good way to facilitate that from the team where you’re not just saying, well, this book says this is what we should be good at.

What do we think? And I’m curious if you have seen– as you’ve done that process at multiple companies with, you know, probably multiple years– if you’ve seen themes emerge of like in general, here’s what managers in an organization that’s trying to have empowered teams, these are the things that we tend to value.

Kevin

That’s a great question. I’ve probably done that exercise now, maybe seven times because sometimes, you know, if your team is growing, you’ll do it again. Right. And, the themes will change as people develop and stuff. But yeah easily like 7 or 8 times at different companies. I think the things that recur end up being very much more some of that practical management stuff, getting better at giving feedback.

And I think very few folks, including myself, feel like, “Oh, no, I’m, I’m an expert at that. I’m done. Like, I’m perfect. I don’t need to learn any more.” There’s things like that that, that come up recurring. But I think one of the interesting things about doing this at different companies or even the same company over multiple years is it does– it is pretty different every time.

And that speaks–and that’s one of the reasons why I do this exercise– is because it is essentially crowdsourcing from the people in the room. What do we as a collective group of managers believe is the most important thing for our culture? And because every company’s culture is different, you end up with kind of a different set of things. Once you get past the kind of the very practical kind of manager skills.

Peter

Yeah.

Kevin

So it might be like I’m not really, you know, so it might be like I need to give better feedback, but it also might be like I have a hard time letting the team step forward. Right? And I feel like I’m too controlling on the team. Or like you know, it’ll be like gives a team autonomy.

And some folks just, you know, have a hard time doing that or the other side too, which is like, you have semi-autonomous teams and people are like, I let the team get away with way too much. Like, I’m not doing as good a job holding the team accountable.

Peter

Right.

Kevin

So it also echoes kind of whatever challenges your organization’s are currently having. And that is also a good reason to revisit the exercise.

Peter

Yeah, that’s great. The Spotify model made it out into the world. And you know, people thought they were adopting a Spotify model. And then when we look at what they were doing, it sounds nothing like what you just described. What do people adopting it sort of second or third hand get wrong?

Kevin

They get a lot wrong. Right? And I wrote an article in like 2014 like after I’ve been in Spotify for less than a year, but as soon as I showed up to Spotify, people started pinging me about.either challenges they were having with the model or whatever.

Peter

I think I was one of them.

Kevin

Yeah, you might have. Actually, I had several conversations with Adobe. Adobe was trying to adopt in different parts the organization. Yeah. And so I wrote this article like you shouldn’t adopt the Spotify model. And the main reason was if you look at the reason people got it wrong is because they look at the white paper and that was the only documentation.

Or they look at the white paper and then ater, Henrik did the videos. That model– I mean, it’s an agile model, like it was continuously evolving and one, it was continuously evolving and two, the way it worked in my tribe, totally different than the way it worked in the next tribe over. Because each of us were doing things to optimize within our own organization.

I would say, because when I came in, I took over what’s called the Music Player Tribe, which was sort of the original, the first tribe, and most of the original kind of employees that were still at the company. So we were, I’d say, of the kind of white paper, we were the ones that were probably the closest to it.

And maybe it was also because I joined, having just read that, it was like, okay, I guess this is what we do. [Right] But so we were probably the closest to like, how it’s described in the white paper, but one, we never– Spotify didn’t care if anybody else did the Spotify models.  Spotify wasn’t, like, you know, BCG [Boston Consulting Group] or like some weird consulting company where we were trying to sell the Spotify model.

Like there’s no certification in the Spotify model, there’s no book on the Spotify model because we didn’t care what people did. We were just sharing knowledge. It was like, this is what we do. Like take it or leave it. If it’s interesting to you, steal some good ideas. But people kind of took it as no, we adopt what’s written in the white paper, but that’s not nearly enough information.

The other part of it that I think people just always get wrong– And by the way, I’ve seen companies since I wrote that– companies did kind of actually, some companies did do it and actually were really successful in some of their misunderstandings of what we did was actually better than what we did. And so, it did kind of –there were companies who found it and were successful, but there were a lot– most weren’t, and a lot of it had to do with also Swedish culture.

Because Sweden is an exceptionally group oriented kind of culture, generally; not just in a company. And so that mentality of we collectively are responsible and we collectively are accountable for what we do. That wasn’t like anything we had to train. That wasn’t anything we had to teach, this was just what people– that’s what people thought. And so that is really hard if you’re an American company or an Italian company or a German company where it’s just different, like a different kind of culture. And so that’s where I think a lot of people got wrong, would be, they’d say, you know, I’d meet with somebody, I’d meet with some other company that was trying to do the Spotify model, and they’d say okay, so when the chapter leader assigns work to people and like, that’s not what the chapter lead does.

No, no, no, no. Like we changed our engineering managers are now chapter leaders. And there’s one chapter lead per team, I was like “That’s not how that works.” But then what are they doing? I’m like, well, they’re in the team. They’re developers in the team. They’re also people managers, but they’re in a team. They’re not. And they’re managing people.

Multiple teams like, well, but that doesn’t you know, it just didn’t make any sense to them.  Or I’ll say, we have this problem at Spotify as well. When we started to hire product managers from other companies like Google or BBC (British Broadcasting Corporation) or whatever, because we hired a lot of those folks, they didn’t understand this model because they were coming from a very hierarchical command and control structure, and they’d be like, well, who’s in charge of the team now?

The answer was always, the team is in charge of the team. “But who do I talk to if the team’s not working well?”

“Please talk to the team.”

Peter

Didn’t you have, like, an early experience when you first landed there? And you’re like, I have this question, who do I talk to? You want to tell the story.

Kevin

As like a new director, like, okay, so I show up and, you know, I’ve read the white paper and everything, but now I’m trying to figure out, you know, I’m actually there, and I’m trying to figure out how something works. And so I ask one of the chapter leads and like, “Hey, I’m trying to understand, like, this team is working on this thing. Who do I talk to about it, in the team? And he is like, “You go talk to the team. All right?”

“No, no, I know I’m going to go talk to somebody on the team, but who on the team do I go talk to you know?”

“You just talk to the team.” And it’s like, whatever. “I just walk into their squad room and just shout out, “How does this work?”

It’s like, “That’s exactly what you do.”

I’m like, “Okay, so I just like, walk into this other room and go, “Hey, I’m trying to figure out this, like, can somebody help me? And then somebody goes, oh yeah, okay, I’ll help. Somebody stand up, “Okay, I’ll help you.”

But I was like, not that what that person wasn’t doing. Yeah. That’s how you did stuff, right? There wasn’t one person. There was “You talk to the team.” And so that was a huge eye opener for me. Just complete.

Peter

It seems like what was written about and described as the Spotify model is not the Spotify model. It’s the result of the Spotify model and the actual Spotify model is like these generative principles.

Kevin

Yes. That’s– yeah, that’s very astute. Yeah, that’s absolutely right. Which is really what the core of the Spotify model was, is 100% agile, a mindset of solve problems, iterate. What’s the problem we got this time? All right. Let’s do it slightly different. And the different– you know if you see like a talk from one of those agile coaches or Spotify or various things, each of them is sort of a checkpoint in time of, hey, we’re doing this now. And it might even be like, hey, we’re doing this now in my tribe. Not like this is what Spotify does. Like, this is what we’re doing and it’s working pretty well. But that’s what was also happening within the company, is you’d see–, I mentioned POCLACs that started not in my tribe. I forget which tribe it started in, but it started in a different tribe.

And it was this thing like, “Hey, we’re doing this thing now and it’s working pretty well.”

And everybody else went, “Oh, that sounds like a good idea. Maybe we’ll try it too.” And then eventually it became what we all did because it was really effective. If you can imagine like 100, 200 like autonomous agile teams all sort of consistently doing the “build, measure, learn” loop and then having ways to share what’s working for them into these communities of practice that the guilds are ideas kind of float around and then other people start to pick them up, and eventually everybody’s doing them. And that was just an incredibly fertile ground for a lot of stuff. And that is kind of impossible to see from the outside.

Peter

Yeah. It reminds me a little bit about the way that Buurtzorg works, which is like a home health care org, right? Oh yeah. And I remember reading or I think I was listening to an interview with one of the nurses and she said, yeah, our team figured out this really cool breakthrough process that was so useful for us. And so we went to Jos de Blok the CEO. And we said, “Jos, we think every team should do this. How do we get every team to do it?” He said “Write about it on the internal blog, and the teams that wants to do it will pick it up.” Like you don’t just tell people to do things, but you share things that might work, right?

Kevin

Yeah, yeah. Yeah, absolutely. And you know, again, like Spotify didn’t invent these ideas out of whole cloth. We stole them, like very openly. Like we stole matrix organizations from here. And we stole ideas from Buurtzorg. Absolutely. Yeah. We were constantly, kind of looking out at the world and seeing what was going on and trying to do this kind of sharing between organizations. It is honestly one of the things I miss most. I’ve tried to recreate various versions of it. It’s just been– it’s a lot harder in America.

Peter

Yeah. That makes sense. Different culture. Right?

Kevin

Oh, absolutely.

Peter

Yeah. So, since then you’ve been, doing CTO type things, right? And I’m curious, in your role as a CTO, how you see the balance between technical leadership and human leadership.

Kevin

It will again depend on, it’s 100% context dependent on the organization I’m leading and where they are on their journey. Some organizations, I’ve really been able to focus a lot because they’re at a pretty good state, on a technology level where I can just really focus on like, how do we become a much more effective, empowered organization; and other organizations like, no like we’re a little bit—we have a lot more to go on the technical side. And so, I’ll try and involve them simultaneously in both in and there is connection between organizational stuff and architecture because we know that from Conway’s Law.

But I think, That’ll depend where I spend the balance of my time. Right? So, some organizations, I am a lot more focused on the technology and just kind of getting us to either a more modern or just a healthier kind of, level there. And part of my motivation there is let’s get us to a good point so that I can now focus on the teams. Right? Because if you’re focusing on the teams and you’re having incidents every day, that’s what’s going to dominate. That’s what people are worried about. They’re not worried about, like, how could we improve cycle time? They’re really worried about how do I not get woken up every night. So, it’s kind of a balancing act. I think It’ll depend on different pieces. I will say, as a CTO, generally a natural place is more, you know, series B, C, D, you know, larger teams. And for that reason, I’m usually very rarely needing to be at a super low level of detail. I’m instead kind of inspiring and directing and reviewing things. So it’s a little bit different. And I also generally have very trusted people that work for me that are extremely good technically. And so, where I’m often bringing strengths to the table is also going to be more on the organizational side because there’s good technical people already in the organization.

Peter

Right.

Kevin

And sometimes I have great organization people in the organization. So I can focus a little bit more on technical. So it always depends on kind of where the ball is, where– you know– where the ball lies when you show up.

Peter

Right, right.

Kevin

But because I enjoy both; because I care about both, I always keep a hand in both. But it’s how active am I? Like, am I learning? Am I trying to learn or am I trying to nudge? On either side?

Peter

What advice would you have for an engineering manager who’s hoping to get a little bit more effective at the management part of being an engineering manager?

Kevin

Okay. So when you and I were coming up, Peter, we grew up in this kind of command and control. Single, “wringable neck” managers like the accountable one, the responsible one, and manager directs the team on the work to do. We’re in a very different world now. A lot of companies are very much more like the manager is the supporter. It’s the lead from behind person. Especially when you have, let’s say you are very far along on your path. You do have fairly autonomous teams. Managers have learned modern management is very much in the back seat instead of driving. So, I think one of the skills I probably had to focus on the most with managers over the last few years has been you can nudge, you can drive. You are the guardrail. Because what I’ll see is I’ll see a team that’s well intentioned, but it’s just kind of all over the place. Right? And the manager is just letting them fail like I’m letting them learn from failure. I’m like, well, you can let that happen for a little while. You can’t just let that happen forever. Like eventually you need to guide them back on the road. And so that’s been one of the skills I probably have spent the most amount of time trying to teach. You’re not their friend, you’re their boss. And sometimes you do need to step in. You do need to question, you need to challenge. And you can do that in a really humane and positive way.

You don’t have to direct and tell and yell, but you should be asking difficult questions. You think it would be a good idea to do this? I’ve got some concerns. Let’s talk about that. Can you explain to me why this will work in this situation? In this situation, right? Because that has been a big challenge for managers that have been really brought up in this servant leadership mindset, which is a better mindset to start from than the “You all do what I say” kind of dictator mindset, but it has its own challenges and we haven’t found a good way to teach kind of in the middle. So that’s one of the skills of being a manager that I think I probably had to focus the most on. A lot of the other skills of management, how to do effective one on ones, that kind of stuff, the nice thing is there’s a tremendous amount of resources now, but nothing like there used to be.

And so I can just direct people to lead dev, or to various blogs or whatever. And I always have them read multiple ones because different people, you got to assemble your own style from everyone else’s what resonates with you. But that kind of part. And we do have like manager training and that kind of stuff at the company that the mechanics of it, is a lot easier to learn now than it used to be, but it is like those softer skills that are harder to pick up.

Peter

Yeah, that balancing act that you’re describing there, is exactly why we developed our three jobs model. Right? Because we saw people go to one of two ends of the spectrum. I’m going to tell people what to do. I’m going to direct. [Yeah.] Or and sometimes they get feedback. They’re like, hey, you’re micromanaging. You can’t do that anymore. And so they’ll say, “Okay, I’m going to be a hands off manager now and let them figure it out. And then you get the exact same opposite of what you described, right? It’s like, “Now the team is just flailing.” And so when we were working with clients, we realized there needs to be a middle path. And it’s really a different way of thinking about it. And it’s really like, no, you have jobs to do. Your job is not to step back and just let them figure it out. You need to create clarity, which includes setting expectations like here’s what success looks like. You have to define success, and then you have to hold people accountable for that. But then the other two jobs, right, are increasing capability and improving the system, because there are certain things that, because of positional authority, only a manager or above can get done in an organization. If you’re going to change team structure, the team can’t do that from within, in almost any company, right? So it’s like those are the three jobs, right?

Kevin

I love no, I yeah, I love your three jobs as well, because you’ve talked about it a lot on the podcast. And I think it is a really good one. I also like– you hit on something that I didn’t say, but I was kind of alluding to, which is understanding your positional authority, and when you use it, when you don’t use it, how you use it, understand how people relate to you because of it, even if you don’t think about it that way.

Yeah. I think that’s an absolutely crucial aspect of it as well, is understanding. If you say something like, I as a CTO, I have to be always careful of this. If I give an opinion in a meeting, that’s what we’re doing. So I can’t give an opinion, until, like I said, unless I think we’re really going in a really unproductive direction. That’s where I might step in, or I might give my opinion last if I don’t feel like we’re making progress, but I’m always–I have to be careful when I speak or I speak and you can think, “Well, I don’t know about this. I’m just kind of thinking about it.” But the minute I say it, that’s it. “That’s what we’re doing.”

Peter

Yeah, I think a lot of people, as they move into leadership roles, overlook that. Then they think because my intentions are good and because I’m trying to empower you and because I say, this is a safe space, I just assume that all the right things are going to happen. And no, like, you’ve got the authority, there’s just no way around it. And it’s not necessarily a bad thing. It’s a bad thing if you’re using it in the wrong way, like we talked about. But there are times when somebody with positional authority, using that positional authority to make the right thing happen in a way that’s human centric, in a way that is, you know, encompassing how people are going to react to it, is absolutely the best way to do it.

Kevin

Yeah, right. You must have seen this. I’m sure you’ve seen this, because I’ve seen this in just people I mentor– things like that or companies have like an actual either deliberately or just organically, have developed a fairly kind of autonomous team culture; an empowered team culture, and it’s just slowly transitioned into this, like, all of a sudden teams are waiting all the time for approval. And then the leaders are like, wait, I don’t understand. Like, we never required anybody to get our approval before. Why are we sitting on this stuff? Why aren’t we just moving it?  Like, what’s happened? And what has happened is not like a deliberate choice or just a new manager comes in or somebody else and they go, “Well, let’s just check on that before we do it.” And just subtly, over time, like you move into a permission culture because you’re not conscious of this, you know, it might be somebody just not conscious of the role power, or like, hey, I want to take a look at that before we finalize it. But, it means, hey can I look at it tomorrow. And also on the teams waiting and then they become– and then they get, “Well, we don’t want to do anything because we’re worried. We need to get approved.” Yeah, yeah. That kind of thing can happen just by people not even understanding their positional authority

Peter

Yeah. It’s like the leaders need to send you know, we call them culture signals, which is like a behavior that’s so obviously unusual that people actually believe you like, “Hey, we want you to review this before we send it out, “and you just say, “No, I’m not going to do that. I trust you. If we get it wrong, we’ll deal with it. But I trust you.” And that would be like people obviously saying what? Right? Like. But you have to do that. Otherwise people just assume it’s going to be the way it always has been.

Kevin

Yeah. Yeah. That’s right.

Peter

Several times you’ve mentioned that it depends on the context. Kevin. That’s nice– It has a nice ring to it. Do you wanna talk a little bit about your book?

Kevin

You mean this book?

Peter

Oh yeah. That one. Well, so if you’re listening on the podcast, Kevin is holding up the book with the big, bold words. “It depends” at the top.

Kevin

Yeah. Thank you. I wrote—so, over the years before I even started at Adobe, I started blogging and as I kind of made this more deliberate move into management, I started blogging more about being a manager and the things I was learning, as kind of a new manager—I had managed before, but is like somebody taking it seriously and just over time, that became sort of more and more what I wrote about. I’m not like an everyday writer, like some of the other folks. But, you know, if I’m mentoring somebody or something comes up and they’ll mention something like, oh, you know what? Yes. Because, like you, I think you were talking about before, now you have a body of all these podcasts, you’re talking to somebody and they’re like, oh, I don’t know how to do delegation.

And you talked about, I know because I just heard it, the episode where you talked about your delegation problem, and you can just refer, “Oh, go listen to that episode. We talked about it there. So over time, as I was mentoring people, some stuff would come up and I would either say, “Well, you know, I actually wrote about this, like, we’ll talk about it for a minute.

And now let me just refer you to the thing,” or I go, “Oh, I should probably write about this because it has come up before.” So, that I eventually had years and years of  blog posts and during Covid, had time to kill and, I decided, you know what? I should look through these, very much influenced by, you know, other folks who too are bloggers and kind of collected their stuff into a single, compendium. I’d say, well, maybe I’ll do that. And I went through and found sort of over the ten years, 2012 to 2022, which includes me being at Adobe, kind of as a director, and then leaving Adobe, going to Spotify and then going from Spotify to being a CTO. So that includes like a significant part of like me moving into software executive at multiple companies.

So it kind of has that growth. And some stuff is written for our directors or CTOs and some stuff is written for engineering managers, or leads. And so I collected those up. I edited because I needed to edit them. But I didn’t really change any of what I said. I’m like, if I disagree with what I said, I just want to include it in the book. So I may have nuances that are different, but generally I agree with everything I put in the book and just put it together in a book. It was published, in March of this year, from the Inner Circle Press. So it’s available everywhere in the world. You can get an e-book, hardcover, softcover, audiobook, read by me, edited with Adobe Audition. And, yeah. And there’s a website, called itdependsbook.net which has the book information there. There’s also links there. There’s a podcast every other week; I serialize a chapter of the audiobook, and there’s a newsletter where every other week I serialize a print article or the text of an article. So if you subscribe to both, eventually you will get the whole book. But, you know, ideally you like them and then you go, you know what? I don’t wait till… So it’s going to take me another six months to get through the rest of it.

Peter

Ya.  Just give it to me now.  It’s worth the money.

Kevin

Buy a book.

Peter

That’s cool. Where else can people find more information?

Kevin

My main website, with links to my threads and Twitter and stuff is KevinGoldsmith.com Just my name. And that’s got links to writing as well. I have a blog, called puppies, rainbows, flowers and kittens because this is like, created in 2003. But that’s blog.kevingoldsmith.com

Peter

Very cool.

Kevin

So and newsletters subs, that’s KevinGoldsmith.Substack.com.  But if you go to KevinGoldsmith.com you get it all.

Peter

You find all this stuff.

Kevin

Yeah.

Peter

Kevin, are there other people you’re paying attention to these days that you think, you know, our listeners, if they’re not aware of them, they should be aware of this person? Like I always say, if you’re not reading current Kent Beck, you should be reading current Kent Beck as an example. Who else comes to mind that’s sort of in that category for you?

Kevin

Yeah, big fan of Kent back. I listen to your podcast, significantly. I actually, for managers, I find myself often recommending there’s a podcast called Manager Tools. Those guys, and actually now there’s those ladies, because it was two guys, now it’s two women. They take a very different approach than I do personally, but they are incredibly thoughtful about why they do things the way they do them. And they explain them well. And so very much like I will find myself stealing ideas from them. [Yeah.] But where I am very, let’s say more agile and just very much like, let’s think about let’s be deliberate and make choices, but let’s not each team, you’re going to do it differently for you than I’m gonna do it for me. They’re very much like, you do it this way.

Peter

Yeah.

Kevin

But when they say you do it this way, they say, this is why we tell you to do it this way. And here’s all the supporting things. And so you go, oh, maybe I’ll take this, maybe I’ll take that. Yeah. So that’s another place, for managers. I tend to really like you mentioned, you mentioned Buurtzorg. You know, I, often recommend the Laloux book to folks;  Reinventing Organizations. That’s why I call, you know, for folks who are interested in management or interested in how to structure organizations, that to me is like, that’s the advanced mode. That’s where we get to think about what we can all aspire to. But, you know, obviously the DORA folks and, all those, all the, books (example) that the three of them have written; Jez Humble, Gene Kim, Nicole Forsgren, like they’re contributors on lots of different books. So that is also a big reference for me. Beyond that, what I tend to do, is follow–there’s people whose Goodreads I follow, and they just inevitably read awesome books. And so, I, you know, I would find people you like either on Twitter or whatever. And so they’re not necessarily writing themselves, but they’re great references. [Yeah.] JasonYip. On Twitter is always reading and referencing what he’s reading. He’s an ex Spotify agile coach. And like, if he reads something and he likes it, I know I need to go read that. Because he’s just really good about that.

Actually, Jurgen Appelo reads a lot of good books. Like, I like Management 3.0 a whole lot, but, he’s also like, a pretty heavy reader, and I’ll read his. Yeah, whatever he’s reading is usually a pretty good indicator.

Peter

I like that– the sort of, these are my curators, right?

Kevin

Yeah, yeah.  Exactly. Cool.

Peter

So, Kevin, what questions do you have for me?

Kevin

So, you all are working with teams and individuals constantly. I think one of the things that’s been really helpful for me for my own growth is mentoring kind of outside my company, because that lets me step outside. And is that helpful? Do you find that you do that a lot as well, to just not be like, with other kind of folks doing the job that’s similar to you?

Peter

Very frequently. We’ll have conversations with somebody, and it just turns into a coaching conversation because A), we’ve developed the skills to do that and, B), we’ve, you know, connected those dots enough that, “Hey, this thing that works at work happens to work in this relationship problem you’re having, friend.” Right? Have you thought about it this way?” Right? “Have you thought about creating a customer profile for your spouse?” What are their jobs to be done from this marriage? Like, we don’t actually couch it that way, but it’s like it’s like a model to think about things. And so I find that all the time. So yeah. Absolutely find this spreading outside of work and that they sort of enrich each other. Like, the more we realize it’s just like it’s just humans trying to solve complex problems together. Yeah, sometimes that’s at work, sometimes it’s at home, sometimes it’s in the community. Whatever. Right. But yeah, it all connects for sure.

Kevin

It’s like me. It sounds like me teaching my daughter kanban to help her manage your homework.

Peter

You know. I think Rich and I both have a video on, like, when our kids were young. Sort of like the time lapse of their kanban boards and stuff. Yeah. For sure. Yeah. I think it also helps us, from a business standpoint is  (I’ll sort of tack this on). But from a business standpoint, it’s made it so that, we end up having clients in all different kinds of contexts that we never would have expected, because, like, somebody had a good experience with us, and they mentioned it to their cousin at the wedding, and then their cousin reaches out to us and says, “Hey, you know, this is a completely different industry than you’ve ever worked in before, but my cousin really liked you. Could you help us?” And it’s like, “I don’t know, maybe. Let’s talk. I can see what your problems are.” And it turns out the problems are kind of universal from company to company.

Kevin

I think one of the things. Yeah. Oh, wow. Yeah, I think one of the benefits or blessings of having been in Spotify, when I was at Spotify is I did– I would end up sharing you know, doing a knowledge sharing session with like the Philips, you know, with a department store in Amsterdam and the Philips health care hardware unit, and the company that makes those four story tall dump trucks, because they were trying to figure out like, “Oh, how do we get some of that innovation into our completely different organizations? And you, after talking to them for a little while, you realize, yeah, like, okay, well, we—we get a lot of benefits in software, because we don’t have to retool a plant to change a design. But a lot of these ideas are actually pretty universal, surprisingly. So yeah, we all learn quite a lot from a car manufacturer, right?

Peter

That’s right. Yeah. And it turns out that, you know, cost of iteration is much lower for software. So we get more reps in. So yeah, that’s right. Kevin, Thanks so much. It’s been a pleasure catching up. And I look forward to checking out all the resources I’ll get on the podcast for sure. And I’ve already ordered the book, so it’s on the way. But great to see you.

Kevin

Yeah, it’s great to see you. Thanks so much for having me on.

Last updated