Drinking from the fire hose — an interview with Kevin Goldsmith
Kevin Goldsmith is CTO at Avvo and former Vice President of Engineering at Spotify. He has also worked for Adobe and Microsoft. He is also the owner of Unit Circle Rekkids/Unit Circle Media where he promotes young musical talents. Personally, he’s a musician and a dad. I had a chance to speak with Kevin at AgileByExample 2016 conference in Warsaw. Afterwards, I invited him for this interview. Kevin is also one of the writers in Agile&Change publication on Medium.com.
Marcin: Kevin, you recently changed your role from VP of Engineering at Spotify to CTO at Avvo. That involved also relocating from Stockholm, Sweden to Seattle, USA. In the letter published on Medium.com you indicated some reasons behind the decision. How do you decide that it’s time to move on to another challenge?
Kevin: There are always multiple facets involved in making the decision. It’s very stressful to leave a role, especially one that you enjoy in a great company. I’ve left roles for lots of reasons in the past.
In the case of Spotify (and Adobe before it), the main driver of the decision was that I realized that I could learn and grow more somewhere else. As I wrote in my post, I learned a tremendous amount working at Spotify. However, I understood that the challenges that I would face if I remained were less interesting to me from the perspective of my own personal growth. At Avvo, I am back to learning by “drinking from the fire hose,” which feels great.
M: How did you cope with the stress? You’ve got a track record of working for great companies. I’d reckon it was always tough to leave. Did you create any patterns or strategies that assist you in the process or to jumpstart the change?
K: I have always had a north star or a goal in my mind. I approach each new role with the idea of where that will take me after. I always ask people who are considering a job change, “What is the job after this one?” I look at each role as an opportunity to learn and grow. It is vital that a role helps me to develop new skills and not just use the ones I already have. With this mindset, I am very deliberate about the career choices I make. Also, when I take a new role, I usually have an idea of what I want to learn, and a timeframe where I will check-in on how things are going. If things are going well at that point, I will set another point in the future to check in. Usually, at one of these checkpoints, I will realize that I am no longer learning new things, or that I am no longer growing in my role or that I am just unhappy. Then I will be open to new opportunities as they arise. It’s very simply asking myself the question of “what would my job look like a year from now? Is that what I want to do?”
It’s always difficult to leave a place where you are surrounded by good people, doing interesting work, for a company that takes good care of you. However, if you want to be continuously growing and improving, it means that you must always find new challenges and experiences. You must make yourself uncomfortable from time to time.
I should be clear that my north star has evolved over time, just like any agile project :) As I’ve grown, I’ve learned new things about myself and realized that my old goals and ideas needed to be updated; because of this I may have taken a more circuitous path to get to where I am now that I would have if my current role was my original goal.
M: In this light what do you think will be the future of work in terms of the things one is going to face and how our economy is changing?
K: If you had asked me this question in the spring, I would have talked about how the continued progress of globalization would lead to increasingly distributed teams; and the corresponding ability for people to choose a job without having to pick a new place to live. The success of the anti-globalization movement in the second half of the year makes me question this possible future, for the near term anyway.
Technology will continue to drive economies across the world and to continue to develop tech skills will always be valuable. In the tech industry, change will remain a constant, and being faster and nimbler will always help your company succeed. Even more so in the future.
M: How to maintain “sanity” with all the changes and trends happening? This might create too much optionality or tension for the people to navigate through — the constant change and looking for faster and nimbler ways to work, freelance or co-location. Some people I know might say we are pushing ourselves too far in this whole turmoil and losing part of our human side. For instance, freelance and remote work create many opportunities like seeing the world and working flexible time which are invaluable but also, after a while, might foster a sense of loneliness and isolation. How do you navigate this new economy scene as an employee and employer?
K: As an employee, I’m clear about what is important to me. For some, they may value the ability to travel at will or the freedom of working from home. For me, those things are less critical than being engaged in teamwork and having discussions in person. The great thing about how work is changing is that there is more freedom than ever in how you can work. You can choose the way you want to work, and find a company that will support it. This is a massive improvement over the old industrial companies where there was only a single way to work. The downside of this is that it requires you to have more self-control, and to be more self-sufficient. I’ll take that problem over the one-size-fits-all approach to work.
As an employer, I can make the choice of how I want to organize my teams. I can structure how we work to how I think the best way is. Then people who want to work that way can come join our teams. I prefer co-located teams (after having worked with remote teams and employees for several years). So the teams I build today are co-located. If someone wants to work remotely they join a company that lets them do that. If they also like working together with a team, then they will join my company. For this reason, I think that the choices people have is now beneficial to me as an employer. I don’t have to worry that someone will be unhappy working with a co-located team, because they have chosen to do that.
I’m a keen reader of blogs and websites that track how companies are structuring their work in new ways. There are always new approaches which we can incorporate to make our teams happier or more effective. When I, or someone from my team, finds an interesting idea, we share and discuss it. Maybe we’ll do a trial to incorporate it into one of our teams, to see how it goes. In this way, we don’t get stale, but we aren’t constantly chasing the “new thing” either.
M: What were some of the new approaches you tried lately (either in Avvo or Spotify)? What I see is that people are different in terms of their character, values, what motivates them and develops them. Those preferences and traits may not always align with one another. How do you foster this ability to change and learn on the successes and failures?
I spend a lot of my time with people I’m mentoring in 1:1 discussions. You are correct in that each person is different in what motivates them and how they learn. While I will do some general things with my organization to create a learning culture, I will work with each person separately.
One of the best things I can do for my organization is to model the culture that I want us to have. For me, that means being transparent, taking ownership of my mistakes, being inclusive in decision-making, celebrating our successes and making sure we learn from our failures. If I did anything less myself that what I ask of the rest of my team, they would see my hypocrisy and ignore everything else.
We just went through a self-selection experiment at Avvo as we were building new teams. A few organizations had tried this out at Spotify, but with limited success. So I was a bit unsure about it, but it seemed to be the right thing for us to do culturally at Avvo.
Before I arrived at Avvo, the product team would often move the developers around, with little say. I wanted to rebalance the scales a bit. So we created the new teams and assigned the Product Owners, but then let the developers choose which team they would join. We were inspired by another Seattle-area company, Qumulo, which does this exercise on a regular basis. After the developers made their choices, the managers and I did our best to match developers to teams based on their preferences and trying to make sure each team was balanced skill and personality wise. It ended up working out really well.
M: What if you were wrong in your assumptions while implementing a major shift in an organization? What would you do then? In some companies, experiments take their toll on people creating the opposite effect that was intended.
There are some efforts that you can roll back, and then there are some that you must roll-forward. There are some you can also pilot to avoid organizational chaos if they are unsuccessful. The trick is knowing what the strategy with each proposed change should be.
Rolling back an organizational change means basically declaring it unsuccessful and reverting it back to the previous state. This is reasonable for things like process changes, where the impact of the rollback isn’t significant.
Rolling forward means committing to the change, and working to improve it rather than scrapping it. Re-organizations would be a good candidate for rolling forward. The disruption of a re-organization is significant. Rolling back a re-organization is essentially another re-organization. If these things happen too frequently, it messes with people’s ability to understand their role within the organization and their mental maps of how things function. Even if a re-organization is unsuccessful, it is better to iterate to a better model rather than try to roll the model back.
Piloting is useful for trying out ideas that can work in localized areas. For example, trying out a new role, or a team structure that isn’t a large re-organization. Most processes should be piloted within a subset of an organization before rolling out to the wider team.
For each change idea, I’d ask: Does this need to be rolled out to everyone, or could a single team pilot it? For things like new team processes, a single team could try it. For things like a career pathing system, it doesn’t make sense to do that in only one team. The time to know success is far too long, and the effort of localizing it is far greater than the effort to change the parts that don’t work.
It also changes how you talk about a proposed change to the organization. You must be clear which strategy you are using for this change so that people understand how seriously they need to commit, and how they can improve it or give feedback.
M: As for building an organizational culture, some interesting insights on this were mentioned in publications by Daniel Pink (“Drive”) or Frederic Laloux (“Reinventing Organizations”). How do you use some of the knowledge provided by them or other authors? Which books, blogs, sources influenced you and the way you build organizations?
I take every opportunity to learn from others that I can. I read books, blogs, listen to podcasts, watch talks, meet with other companies to share knowledge and talk to peers as often as I can.
Diverse perspectives make me challenge my own world view. They make me consider why I think the way I do. Challenging my own preconceptions helps me better articulate my reasoning. It also tends to teach me new things as well.
Both “Drive” and “Reinventing Organizations” were influential to me as well as “Turn the Ship Around,” “The Five Dysfunctions of a Team”, “The Seven Habits of Highly Effective People”, “Leading Change”, “The Advantage”, “The Hard Things about Hard Things,” and “Zero to One.” I have a pile of real and virtual books, that I am reading and adding to constantly.
I listen to the Buffer podcast, Boss Level, and Management Tools.
I follow many blogs and people on twitter, but beyond “Rands in Repose,” and Ben Horowitz’s blog, I get inputs from all over.
I follow tons of Agilists and leadership thinkers on Twitter, and tend to get a lot of interesting links that way as well. I tend to retweet the articles that I find especially good, so you can follow me on Twitter (@KevinGoldsmith) or see who I am following.
M: What picture of the forthcoming trends do you see based on your experience and the people you follow? In a recent conversation with my friend we pondered on how the agility is changing. We noticed a distinct trend emphasising the delivery aspect, achieving concrete short and long-term effects. Were do you think we’re heading?
I was thinking about the evolution of agile this week. Earlier I saw a tweet from someone saying that agile was getting stale, getting mired in the certifications and professionalization. On the other hand, I spoke at an Operational Excellence conference this week, and saw first-hand, how agile is smashing into the process-oriented worlds of things like Six-Sigma and industries like finance and manufacturing.
Since I started working agile 17 years ago, I have seen it evolve greatly. Incorporating ideas from TPS, Lean Startup, organizational design, organizational health, servant leadership, and countless other areas. Kaizen as part of a strong agile practice is still evolving.
Agile as a practice is agile itself. It will continue to grow and iterate to improve as new ideas enter the lexicon and problems arise to be solved. Scaling agile is still a challenge, and that is where I think there is still much work to do. I think truly scaling agile means evolving organization models to support it, and we’re just getting started there. On the team level, I’m waiting for the next evolution beyond ScrumBan at the upper end of Agile. At the newer side, I still see many companies struggling to make a transformation to Agile, so I think there is a lot more innovation to be done there.
What I saw in the earlier days of Agile was that the scrum master or XP Coach was very much concerned with business outcomes, As the profession matured the role of the Agile Coach grew to where their focus was purely on the health and well-being of the team. Often the coach acted as a counter to the engineering and product leadership. I have seen coaches who have gone so far down that road (or never had the delivery experience as you mention) becoming an impediment to the team’s success and velocity.
It makes sense to me that if some companies have had this experience that they would want to refocus the role around delivery. If having delivery focus becomes more common as a job requirement, I can see it refocusing the role.
I don’t think the lack of delivery focus is reflective of the whole industry, but more comes from people who have come directly into the role. Many Agile Coaches I have known and worked with come from development or product backgrounds and so are aware of the necessities of delivery. Potentially, it is a matter of giving more training on project management and business necessities in the programs that are currently training coaches.
Thank you Kevin very much for your time and sharing your thoughts!
