Creative Leadership, Context Over Process, Remote Scaling, AI as Amplifier | Kevin Goldsmith, CTO at DistroKid
Now CTO at DistroKid, Kevin Goldsmith leads the engineering vision behind one of the world’s largest independent music distribution platforms. His career includes key roles at Spotify, Adobe, Microsoft, IBM, Anaconda, and Onfido, where he’s consistently blended deep technical execution with a creative, systems-thinking approach.
What makes Kevin stand out is how he draws from his background as a musician, writer and photographer to lead with artistic curiosity, strong observation, and adaptability. He’s also the author of It Depends, a book exploring why great tech leadership is never one-size-fits-all.
Highlights
Creative leaders see patterns that process-driven ones often miss
Hiring based on roles is easier, building based on context is smarter
“Best practices” are often just good habits in the wrong situation
Teams with real empathy spot friction points users never report
AI won’t replace engineers, it’ll reward those who ask better questions.
Yassine: As both an artist and a technology leader, what influence does your artistic part have on how you manage engineering organizations?
Kevin: To succeed, an artist must be an independent creator, collaborator, and team leader. Artists can work alone, chasing their muse for long stretches, but they have to work with others to execute things on a larger scale or get their art in front of others. Being an artist requires both artistic vision and an acute power of observation. Attention to detail. It involves empathy and seeking to understand. It requires inquisitiveness and, of course, creativity. Learning through experimentation and failure. An artist must solve problems and work within and outside constraints as the situation demands. An artist must know the rules and when they can be broken or bent. And that bending of the rules redefines what the rules are.
My constant efforts to be a better artist inform how I approach leading technology teams and vice versa.
Y: You gave a talk on finding the right ingredients for one’s perfect team. What would you say are YOUR ingredients for your perfect team? Does a music distribution platform require a specific breed of software engineers?
Kevin: There is no one perfect team. There is the best team for the current situation. The required mixture of skills and experience that suits the problems to be solved. The personalities that both support and challenge each other to bring out the best work of everyone.
That said, the teams that have a diversity of skills, a diversity of experience, and a diversity of personalities have generally outperformed more homogenous teams in my experience.
In that talk, I don’t suggest that the ingredients for a perfect team are “one backend developer, one full-stack developer, one tester,” or anything like that. I suggest that the team members look at themselves across a range of elements critical to the team's work and map the results to see where they have good coverage as a group and where they need to develop. The goal is to build a well-rounded team with the skills, experience, or even personalities to make it more effective.
A music distribution platform is, in the end, a software platform. It doesn’t need a specialized type of software engineer to build it. However, engineers working on any project will be more energized, engaged, and excited if they understand the customer they are creating for. Many people on our teams work at DistroKid because they are musicians and use the product themselves. They empathize with the artists who use the platform because they are artists and are often part of artist communities. That empathy allows them to understand the “why” of a feature or how a seemingly minor bug can cause a lot of frustration for a user.
Y: In your book “It Depends,” you highlight how leadership dynamics are supposed to vary from one organization to another, and from one person to another. How can engineering leaders balance breaking free from prescribed best practices without reinventing the wheel for each decision?
Kevin: “Best practices” can be a trap because often, they are developed in one context but are assumed to apply to other situations that are entirely different.
I frequently encounter the problem of a small company hiring a senior leader with most of their experience at a much larger company. That person starts trying to implement the best practices of their previous employer and creates unnecessary processes, frustration in their organization, and eroded morale. That is an obvious example, but companies each have their own culture or ways of working, which may be true even from team to team within a company.
The important thing is to understand why the best practice exists. What problem was it trying to solve? What was it about that solution that worked in that context? Approaching the situation with an open mind and some curiosity means you can often adapt that best practice to your situation instead of misapplying it.
A core message of my book is that leaders need to be deliberate in their decisions and aware of the potential impacts of those decisions. A big part of that is understanding your organization: what works well? What are the common blockers for your teams? In Systems Thinking parlance, what are the bottlenecks? Understanding the system you operate in helps you define the best practices specific to your organization and redefine them as your organization evolves.
Y: Based on your experience building and managing global remote teams, what advantages can small and mid-sized companies gain from international talent that they might not be considering?
Kevin: The hardest part of having distributed teams is maintaining consistent communication from individual to individual and from team to team. That problem is exacerbated by scale. So, the larger the company, the harder it is to ensure people have the information they need when they need it. It’s the n^2 communication problem (the number of communication connections between n people approximate n^2). Small and midsize companies can take advantage of a smaller n.
Small and midsize companies also have a more consistent company culture than larger ones, making it easier for employees of different national cultures to feel like they are part of the company, especially if those companies include people from many other national cultures in the same teams, which is also more likely in smaller companies.
Smaller companies also adapt more quickly by their nature. So, distributed employees can feel like they have more impact and the ability to change how the company operates to make it work better for them.
Y: In light of all the ongoing conversations about leadership and AI in engineering, what aspects do you think we're not talking about enough?
Kevin: Every other conversation I have these days is about how the evolution of AI is changing or will change our profession and industry. There is no denying that how software development will work in two or three years will be very different than how we did software development last year or the year before.
I have been in the industry long enough, though, to remember that we’ve had the same conversations about many other innovations in software development. Moving from punch cards to compiled languages to interpreted languages, from command line interfaces to graphical user interfaces, were all attempts to make creating software easier for normal people. BASIC felt like Vibe Coding when the only way to develop software before was to use punch cards or COBOL.
Each technology that people expected would be the end of professional software development became a tool that professional software developers incorporated into their workflows to let them create even more sophisticated software than was previously thought possible. At the same time, these new technologies lowered the barriers to learning software development, which ushered more people into the industry.
While I think there is a lot more work to do before AI can consistently generate reasonable, high-quality code based on my experience, what I’m interested in is what new software innovations developers can create if we can let AI automate the easy, known, stuff that still takes most of the effort on current software projects. That, to me, is much more exciting than worrying about AI independently developing applications that take very little creativity or innovative thinking to build.
Thank you Kevin for your time and insights!
This interview is part of the “Exec Engineering Dialog” series, where I interview seasoned tech leaders on the topics of talent, product, management, and culture.
If you liked the insights shared in this interview, consider giving feedback and/or sharing it with your network, it’s the best way to help this segment improve and grow.
Yassine.