People & Culture

Stride Tech Talk: Ryan Nash (VP of Technology at Gust) on Leadership, Building Great Teams and Maintaining Company Culture

Stride CEO Debbie Madden sat down with Ryan Nash, VP of Technology at Gust, to discuss his unique perspective on issues affecting today's tech leaders.

Debbie Madden, CEO at Stride interviews Ryan Nash, Vice President of Technology at Gust

Debbie: You’ve been the VP of Tech at Gust for almost 2 years now. What advice do you have for developers that aspire to one day work in a VP of Technology role?
Ryan: If you want to take on a leadership role in technology that involves being responsible for people’s careers, I’d suggest you establish a satisfaction with managing people. One thing I often see in developers with leadership skills, is that they get exhausted when it comes to organizing the soft science of motivating people. It’s the exhaustion of dealing with so many views and needs; needs that are not as easily prioritized or debugged. Often times, developers view technology accomplishments as measures of success-- “what did we build this week”. They aren’t measuring success by “what did we achieve as a company, a team”. But, to be a leader, you need to be enabling your people to move the technology, not necessarily building it directly. You want to be the force multiplier and feel accomplished when you do it effectively.

When leaders of a company consider you for a tech leadership role, they assume you have the tech know-how and engineering skills are basically table-stakes. By also being an active participant in strategy and the development of the company, you set yourself apart. This involves communicating with a lot of people and truly understanding how to work with all sides of the business.
Debbie: Can you be a successful tech leader if you don’t want to do the soft skills? I’ve known many solid senior developers that have said they truly enjoy being in the code and don’t have much interest in the people skills side of thing.
Ryan: Then I’d suggest asking yourself what you really want out of a leadership role. You can be a technical leader without managing people. That consists of a lot of leadership by example; you’ll work with and coach your fellow engineers but not be directly responsible for their career development and performance. You can also get a lot of say in company strategy and direction-- I depend on my developers’ participation in those activities all the time. It is all about what your organization needs at a senior level.

Success is happiness. For folks that are truly happy inside the code, I would recommend keeping that passion alive and pursuing leadership within your discipline. For those that want to sit on both sides of the table the best advice I can give is to get very comfortable having uncomfortable conversations. This is almost directly correlated with success in managing people. Surround yourself with passionate and brilliant people that are only happy when executing at the top of their game. Then make it your top priority to remove any obstacles that are preventing those people from performing at that level.

It all comes down to hiring. Which is uncomfortable conversation number one. People need to discuss titles, compensation, roles, and where they fit in the company. Every step of the way, you are having what’s perceived as uncomfortable conversations. The people you hire will have these tough conversations with you. You won’t be brilliant all by yourself, you have to leverage these daily interactions to achieve success. The best analogy I can think of is software architecture. If you want to build a system to scale, you’ll decouple it. When you are a CTO or VP, you are doing this with humans. You need to foster innovation, collaboration, and effective communication between individuals. The well defined interfaces of this human system are working processes, feedback and well understood expectations. Be ready, if you surrounded yourself with smart people they will constantly be pushing the boundaries and contexts you keep building. Each new hire is a new constraint on the system. Each will change the topography of the architecture.
Debbie: Great analogy. Complex architecture works best if the pieces flow and add value to the rest of the system. Great teams work when they have strong foundations and those ongoing perceived difficult conversations to ensure there’s high trust and constant communication.

What do you wish you knew on your first day as VP of Engineering at Gust that you know now?

Ryan: Two things. First - maintain a fresh perspective as long as you can. When I first came to Gust, the whole domain was new to me. I wanted to dive deep into the architecture and market, feverishly learn. But, that’s irreversible. Once you are in the camp, see what everyone else sees, you can’t fake not knowing it. There’s no substitute for seeing things for the first time. Don’t rush into knowing everything that everyone else knows.

Second - Question everything. This is enabled by the first. There’s the temptation to not really ask what is the value to the user from absolutely everything you see. If you question everything, you’ll pull things out of people that they don’t even realize are important, or find things are unimportant even though people have been thrashing on them. Coming in to a new company, whether it’s 10 or 1000 people, they all know the business better than you. It’s easy to not ask questions; you don’t want it to be easy.
Debbie: What’s your biggest fear?

Ryan: I’m not a big “fear” person overall. People often confuse fear with unknown, things you haven’t acknowledged and put in processes to mitigate. So if we, temporarily, redefine fear as something you don’t want to happen so you work actively to prevent it… I do fear that as we grow we risk eroding our culture. We have one of the best teams I’ve ever worked with. I fear we’ll be victims of our own success and growth will make it more difficult to maintain-- I’ve seen it happen before. I guess it will take a lot of uncomfortable conversations to ensure that doesn’t happen; looking forward to it.