079 - Team building and growth with Via's Rodney Cox

Rodney Cox, VP of engineering at Via breaks down his rapid rise into software leadership, how he’s building his team, incremental growth and his approach of stretching beyond his comfort zones.

If you enjoy this episode, please consider leaving a review on Apple Podcasts or wherever you listen.

Please send any questions or comments to podcast@pluralsight.com.

Josh Ruggles:

Hello, and welcome to All Hands on Tech. I'm Josh Ruggles. Today's episode features my conversation with Rodney Cox. Rodney is the VP of engineering at Via, which provides mobile solutions for e-commerce companies. In our conversation, Rodney shares his philosophy on incremental growth, team building and stretching beyond your abilities. Let's listen in. So let's just start with what got you into technology.

Rodney Cox:

Yeah. So it's interesting. I'm honestly kind of envious of the kids that grew up programming, coded all through high school, built apps because that's definitely not me. I started learning how to code when I was 24 and I'm 31 now. So what I saw was like kind of a new age of technology coming and I've always been very entrepreneurial. And so I looked at technology as a way for me to differentiate myself. So I always was kind of curious. I think that with engineering, you have to be a curious person just because solving technical problems requires a bit of investment and buy-in into solving the problem. And if you don't have that conviction, you'll end up giving up or not figuring out the problem.

Josh Ruggles:

You started your career at RiskRecon. So tell us about that.

Rodney Cox:

Yeah. I feel super fortunate. When I was in the first year of my master's program, a guy by the name of Kelly White came and presented to my class. He'd been coming for the last 20 years to give annual presentations on data security. But the year he came to my class, he was presenting on a company he was starting. And everything he said about the business, the space and the opportunity really resonated with me. It really piqued my interest. And at the time, I had been working on my own apps that the university was going to push to the students to help kids find jobs and internships more easily. But as I heard him talk about this business that he was building and it was already validated, I was just immediately drawn in. So after the class and his presentation was over, I walked up to him and I said, "Hey, Kelly, how big is your company?" And he responded, "Well, right now, it's just me. I put out two offers this weekend."

And I was immediately taken aback and I was like, "Well, do you need any help? I really believe in what you're building and I want to be a part of it." And so that night, I went home and I fixed up my resume. I sent him links to the apps I had built and told him that I thought what he had was a home run and I'd like to be a part of it. And then I interviewed and the two guys he hired before me, they liked me and it really accelerated from there. I feel very fortunate that I was able to get into what would be a successful company. Ended up being acquired by MasterCard after five years at the very ground level because it showed me what a business needs from a technological and from a business strategy perspective through various stages. From three to four people in a 12 by 12 office to 120 people doing business with the world's biggest brands. And there's a lot of moving parts in each stage of the business.

And from a technical perspective, there's a lot of different technical needs that will help the business thrive at those different stages. For example, when it was just Jesse Card and I building out the core components of RiskRecon, what mattered is that we got our MVP finished, that we had a product that we could sell. We didn't need robust processes with poll requests and a bunch of code reviews. We didn't need perfect code, we needed a working product. And as the company matured, the processes needed to mature as well. As we brought on more devs, we needed a better documentation. We needed to ensure that our app never went down. That's just a few examples of how as the business evolves, the technology requirements do as well. And I was able to see that and witness and learn and I think that's a huge reason and a contributor to where I'm at today is I almost got, I would say, a career in fast forward.

Josh Ruggles:

For sure. I like what you were just saying about the process initially was kind of not there because it didn't need to be. You just needed moving parts that you could sell. And then over time, you needed to go back and rethink process. How did that go and what were some of those learnings that came out of that?

Rodney Cox:

Yeah. I think that the term right sizing is so important with technology teams. Agile has taken the world by storm over the past 20 years. However, there's any number of different permutations of what Agile is and the reason why is because every team is different and it's made up of different engineers and each of those different engineers have different strengths and weaknesses. And so you kind of have to balance what processes work and what processes are really needed. So I think one thing that has really set me apart in my career and in my ability to add value to the business is really being able to understand the balance between technology needs and business requirements.

Josh Ruggles:

I like that. So let's talk a little bit more about that balance. How do you create this balance? What is the framework for this?

Rodney Cox:

I think it comes down to you being an advocate for the business. So myself, I am I would say business first, technology second, because the whole reason we come into work every day to write code, it's not so that we can have the end of the day, a program that has a hundred percent test coverage. We come into work to write code so the company can make money. And so the decisions you make as a technology leader and just the technologist, I think they always need to be rooted in how does this benefit the business? And yeah, I think that's the way you can analyze the processes. If you're putting in too much process too early, what you're going to see is your product isn't being developed as fast, competitors are developing faster. They're winning more deals, you're losing them. And so that's a sign that maybe you're spending too much time in certain areas. Now, it's hard to really get that spot on in the first go because the deal you might lose in a month is a result of today's processes.

And so I think it takes a lot of awareness to be able to identify changes that need to happen very quickly and to be able to iterate quickly. I definitely think it's smart to stay lean on processes until you realize they need to be added.

Josh Ruggles:

For sure.

Rodney Cox:

Like the term top heavy, it's very easy for our process to become top heavy and you don't realize the effects of it until sometime after.

Josh Ruggles:

Until the damage is kind of done.

Rodney Cox:

And the damage is harder to undo because it results in lost business. Whereas if your process are lightweight at the start, yeah, it might cause some damage, but I just feel from my experience the damage from lightweight processes not being robust enough, it was easier to mitigate the cost of those as opposed to being slow and becoming irrelevant.

Josh Ruggles:

Sure. I mean, it's like just shipping it versus perfecting it and iterating. Like kind of the, I mean, I guess the emo for these days.

Rodney Cox:

So it's interesting. So I don't know if you're familiar with Waterfall versus agile, but you said the word iterate and I think the word iterate is key. The more you iterate, the more you're able to assess and make small tweaks, and small tweaks are much better than the big tweaks. Over-processing, if you think about it, it's more of a waterfall mindset. You're trying to predict what you're going to need in three months, as opposed to let's do something little this week, see how it affects us next week and then make changes where they're needed. And I think the cadence of you having to iterate as the business matures will decrease because you'll kind of get in a groove and your team will create a culture and an identity, and it'll help you hire the right engineers that fit that culture. And you end up with a good tech team.

Josh Ruggles:

Yeah. It's hard to reverse or come back from a big jump. You can walk back or reposition if you make a small mistake. But if you're predicting these big changes, making these big changes, it's a lot harder to reposition after a change like that. So let's go back to RiskRecon when you got to this stage of needing to build out some process. How did you do that with the team? Because you go from kind of a loose system to more structure, more accountability, all those things. I'm just curious how culturally that impacted the team.

Rodney Cox:

Yeah. That's a great question. And as I reflect on it, I think one of the things that stands out is that any type of process we were implementing was typically rooted in some sort of automation, some sort of efficiency improvement. So let's look at shipping code. When we first started, we were using Docker and we'd build a Docker image and then we'd push it up to the repo and then we go through the web browser and AWS and we'd manually update some stuff. And one of the first processes we put in place was, let's automate these deployments. Let's have it make a script that automatically builds our container, pushes it up and deploys our app. Now that in itself is a process, but it's also an automation that saves time. And so that kind of takes us back to that business first mindset of what processes are going to accelerate the business in a healthy and safe way, and that's one of them.

And so now you're shipping code continuously. It gives you the opportunity to then add in testing in your deployment pipelines. Build in tests to say, hey, let's make sure that the code that these 10 developers were working on is working as they expect it to, rather than saying let's build this app and let's write a bunch of tests right now. The decisions were always, how do we streamline things? And as we streamlined, the processes almost fell into place.

Josh Ruggles:

Moving to your new spot at Via, let's break that down a little bit and how some of these learnings of making small changes and really just, I mean, I like the way that you said we're just streamlining instead of we're building processes, because streamlining, I think, it explains a lot, but it doesn't feel like it's overdoing it. So I'm curious how you pulled that into your new role.

Rodney Cox:

Yeah. It's cool. It's almost like I jumped in a time machine. Via, we just raised a seed round have a growing business, but I was the first one to come in with engineering leadership. The team has been outsourcing engineering and it's kind of just been what we call cowboy coders where the customer requests something and they build it. So my role is to come in, step in and build out the team and the processes. And one of my MOs at this point right now is how do I come in and add immediate value? And that's not by implementing processes immediately. It's more engaging what the team, the product needs. And building the team, I think, is the most important part, bringing the right people in at the right time. And so I have a lot of the things I've learned at RiskRecon in the back of my mind in terms of processes I'd like to implement. However, I'm holding off on implementing anything until I bring in additional people that I know I can trust and rely on and also get their insights as well.

Because my process might not be the best for my right hand man or the guy after him. I want to bring these people in and get their opinion, kind of brainstorm, let them know what my thoughts are based off where we're at and what I could bring from RiskRecon to implement as well as listen to them to hear what process has worked for them. That way we can come up with some sort of hybrid model that works the best for this team. Because let's face it, I didn't just grab everyone and everything from RiskRecon and come to Via and just plug and play. It's a different business, it's a different team, it's a different everything. And so although my experiences are valuable, if I was to just implement everything right now my way, it wouldn't be right-sized, it wouldn't be calibrated and that it would become top heavy.

Josh Ruggles:

Yeah. I want to dive in on what the right team is and how you build that.

Rodney Cox:

Yeah. I've got a couple of core principles that I really believe in. And I call them lieutenants so I'm looking at bringing on two lieutenants. I've got one starting in a few weeks. I want them to have the same characteristics as I do in terms of business first. I like to consider myself a CEO's engineer, meaning that I'm looking out for the business. And so the people I bring in for these next key roles need to have that same mindset and I'd like them to be cross-functional individuals, but in their own regards. So I want someone who's very good at front end, understands product design, everything from thinking through the user stories, specking it out, knowing project management really well and how to divvy out tasks. And then someone from a backend perspective who knows how to scale back in systems. And knowing that both of these individuals will be business-minded will ensure that we have the right parts of the technology covered, but also that we're covering them from the right approach. One other thing that I think is really important too is team sizes and team responsibilities.

So from the leadership perspective, yeah, I will want a front end guy and a backend guy, someone to own each of those domains. But I think when you get down to the lower levels, I really like teams of four. I think that there's a reason the military has squadrons, groups of four people. And these groups of four people, they should be cross-functional teams, two people that know front end really well and two people that know backend really well or DevOps. In that way, as we have an onslaught of customer requests that we're not saying, hey backend team, work on these three to four things simultaneously, and hey front end team, do the front end tasks for these three to four things. It gets really hard because you get a lot of crisscrossing and you can lose efficiency. So if we can break up these features that are requested in the new product into a bite-size feature and give it to four people and know that they can carry it out and build everything from design to delivery, I think it's really important.

Josh Ruggles:

I really like that. So as you grow with Via, would you intend to essentially start stacking these teams of four, I mean, to do different things and essentially try to maintain some sort of semblance of that as you grow?

Rodney Cox:

Yeah. Think about it like a pyramid shape. But the one pitfall that I think the pyramid shape tends to have is middle management. And I learned a lot from Mike Fowkes. Mike Fowkes was RiskRecon CTO. And from the day he came on about five years ago up until today, he still cods. And I intend to continue coding at the ground level regardless of how high I get into management. I think it's very important to be on the ground floor and see what the, quote unquote, troops are saying. And so as you start layering these levels of management, I think it's very important that at each level there is still a hands-on approach and a heavy involvement in the development of the product. And so right now, let's say the front end lieutenant comes on, he's going to oversee everything from working with the designer, breaking out user stories, creating sprints and coding. I think that as the layers start adding up underneath him, the parts of the work that he will do will slowly silo somewhat. So he might be more of a big vision.

He'll take care of the design aspect, working with the designer, breaking out user stories and the things he's not doing is coding the CSS for the buttons to make sure that the corners look just right.

Josh Ruggles:

Yeah. I like that because I'm just trying to think, how do you balance that as you get bigger? And how did he [inaudible 00:19:37] or how do you intend to balance this? You know what I mean? Because I totally understand the idea of always wanting to be in the code and being able to look at things and get in there and understand what your team's actually producing. I mean, I'm just trying to figure out how you build that out.

Rodney Cox:

Yeah. And I think it's way easier said than done. I don't think it's clearly broken into lines that your responsibilities will stop it at CSS and they start at JavaScript components. It's not that clear. I think what's really important is first off hiring the right people, not just at the management level, but down on the ground floor for the purpose of being able to find people that are really passionate, that want to own things, that want to have ownership and want to grow. I think that's one thing that stood out at RiskRecon was individuals who you could tell were excited to come to work on Monday because they enjoyed what they were building. So getting people to still be involved, I think, involves making that they're in situations where they feel like they're still learning and growing. I think everybody wants to learn, everyone wants to grow.

And so identifying certain roles and tasks that align with individual's desires, growth desires and learning desires is really important because then it kind of just goes into cruise control. You know that if they really own and care about what they're doing and they want to really master their craft, regardless of their management responsibilities, they'll still make time to learn and improve that thing that they're passionate about.

Josh Ruggles:

Yeah. I don't think you said autopilot, but I kind of got this idea of like you kind of can let them do their work and not have to be hovering or anything like that. Is that...

Rodney Cox:

Totally.

Josh Ruggles:

Yeah. So how do you build that trust on both sides of the fence? Build that trust for you to understand that we're doing it and them have trust in you to know that you have their back and you're going to be there when they need it and not the micromanaging guy.

Rodney Cox:

It's really cliche to say, but it's a Google phrase and it's hire hard, manage easy. And so I think it all comes down to people. And I don't like the idea of hiring people based off of coding languages they know or frameworks they're familiar with, but kind of people that really take a lot of ownership in things, people that I can tell are passionate and curious. So I think micromanaging is bad, really bad from an engineering perspective. And maybe in certain occupations, it's good. Maybe on an assembly line where products have to come out perfectly, but the whole concept of software engineering and building new products and innovation, it's very abstract. And by hovering and giving specific instructions on how to do things is essentially removing the engineering component from the work. And I think people become engineers because they want to engineer things. And so when you strip them of that, they will first become disinterested, and second won't do great at work.

So ultimately, I think it comes down to people and bringing the right people on and finding what they're good at and what they want to do, and then helping them thrive and grow in those situations and positions.

Josh Ruggles:

How do you course correct if you feel like the team is de-motivated or something like that?

Rodney Cox:

I think the first step is assessing why they aren't succeeding. Maybe it's something they're not passionate about. How can we restructure the team to get them on projects that get them excited and engaged? That's one way and I think that's a problem you can fix. I think where it gets more complicated is when you have someone that's genuinely uninterested in the business's success as a whole. And I think it's kind of pretty straightforward. The process is there. It's tougher conversations, but it's not in a punitive way, but in a, look, we want you to be successful. This is what we need. How can we help you get there? How can we help you contribute [inaudible 00:24:15]. Ask them if it is the team they're working on, ask them if it is the project. If it is, what project can we get them on or what changes in their responsibilities can we make to make sure that they feel like they're learning, growing and engaged?

Josh Ruggles:

What do you think are some key elements of a leader?

Rodney Cox:

So I'm going to kind of backtrack a tiny bit to talk about why I came over [inaudible 00:24:38] and joined this new start up. And one of the reasons is I like the fast paced environment, the growth opportunity, but also being stretched. I feel like when you're not being stretched, you're not growing. For the past five years, from a technical perspective, I grew tremendously. I wore every hat you could wear at a tech company, whether it was building out infrastructure to writing front end code or doing machine learning, I had to do it all. And I'm definitely learning as I'm going. But I think the core principles of understanding people and helping them succeed is probably the attribute of a leader that matters most and I think that matters at any level of an organization. And so, I don't know, I'd like that to be my MO. What that looks like from a process perspective I think it's still untold. Like I said, I took this role to stretch myself and forced me to grow.

I think if we were to have this conversation in four years, I'd probably be able to have a lot to say about this is what I did and this is what I learned from it.

Josh Ruggles:

I love that. One of the reasons why is because I feel like there is some engineers that may be reluctant to become a leader. How do you advise them to plan their career and help them grow?

Rodney Cox:

You need people like that. If engineering was about becoming a leader and that's what your whole organization was built around, you wouldn't have a successful engineering team because everyone would just want to manage people. You need people that are extremely passionate about code, that want to just write great code and continue learning. And so if we go back to that pyramid analogy, you've got someone there at the bottom. Bottom doesn't necessarily mean bottom at a compensation level. It means-

Josh Ruggles:

Or respect.

Rodney Cox:

Or respect or clout or anything like that. It's about the role they're playing for the business. The bottom of the pyramid is the foundation if you think about it. So as these individuals who don't have interest in leadership start to learn and grow in your organization, you grow them laterally by giving them more low-level responsibility in terms of architecture and algorithms and systems design. That has nothing to do with people management, but it has everything to do with the longevity of your product. So I'm able to say that just because, like I said, I learned a ton at RiskRecon and I saw individuals who were far better engineers than I am. And they don't have any interest in managing people and that's great. There's a leadership path and there's, I would say, an engineering path, and one isn't better than the other from a compensation or just a respect perspective.

Josh Ruggles:

How do you make sure that they feel valued and how do you bring them along for the ride? You know what I mean? So let's say you hire these lieutenants that you were mentioning earlier, and two of them are your crack guys, they can figure out any solution you need. The other two have the more managerial mindset and more of the business acumen. How do you make sure that those two that are your crack team, but have no interest in management, how do you bring them along and make them feel like they are as important?

Rodney Cox:

Yeah. That's a great question. I recently just finished a book called How To Talk To Your Developer and it's written by Jeff Lawson, I believe. He's the CEO and founder of Twilio. And in the book, he quotes a survey that talks about a bunch of engineers and the percentage of them that play music or do photography or videography or mountain bike or lift weights, it would blow your mind the diversity amongst engineers. And so in our roots as engineers, we're all creators and we like to express ourselves, whether that's through playing music on a guitar or putting paint on a canvas or putting code into an application. They're all forms of creation. And one thing that all creators care about is their work being valued and I think everyone wants to be valued and recognized. And so while the people in leadership roles, they might have more just immediately apparent successes just by the fact that they have a, quote, leadership title, which doesn't mean anything, in my opinion, I think it's very important to recognize every win of every individual.

So when you have your company all hands, it's not about you talking about what your team did, it's about, hey, look at what Sultan did or look at what Dan did. And Dan might be this hardcore engineer that just wants to write code. People need to know the things that he created or the things he did that helped the company. And so I think constantly having a culture of recognition and accomplishment is very important across every facet of the engineering team.

Josh Ruggles:

Let's go into product just a bit. Break down for me your philosophy on architecture and how you roadmap something out. I mean, how much interfacing do you have with the product managers and different things like that? I'm just curious kind of your philosophy and kind of if you have any tenants that you follow as you're outlining the next product or the next big thing.

Rodney Cox:

Interestingly enough, during my tenure at RiskRecon, we never actually had a true product manager. Kelly, our CEO, he's the visionary and he was essentially the product manager. So he would kind of determine roadmap and he would envision a new feature or a big idea. And it would be very much that it would be a big idea and it would need to be iterated upon and have all the details flushed out. And you don't make assumptions and decisions about what the product should do based off of your thoughts, you think about the customer. So like right now, we're going through a redesign. And we hire a design firm and they give us these designs and there's a couple of components there that are complete assumptions about what the end user might like or might want. And so my feedback was is that we need to get a couple of our flagship customers and our customers who use the product the most, let's get their eyes in front of this. Let's give them a couple options and let's see what resonates most with them.

I think one of the most important parts about product development is identifying your target user. A lot like in marketing, your target market, you need to identify who your target customers are and use them as a model. So if big banks are your customer and your service is a security product, you identify which of your banking customers and you're doing security products, which banks have the best security and allow them to help guide your product in the direction it needs to go. Because we're product builders. We need to find everyday users who are really good in the space that the product is solving problems in and relying on their needs to kind of guide the direction of products and features. And I think a result of letting people that are visionaries in the space that are buying the product guide your product is that typically they're early adopters and you'll find that the product you're developing through their guidance is actually something that's going to serve the greater market as the market matures and progresses.

I want to be very clear that let's not just identify one customer. Let's create a persona of what our ideal customer is. And as we talk to five customers about a certain feature or a certain look, what we're able to do is see where the overlap is, see what resonates the most across all of them, and that helps us build something that will be applicable to a much larger segment of the market.

Josh Ruggles:

For sure. With building product and using your customers as basically your barometer, I mean, that totally makes sense, obviously. How does it work? You said Kelly, from your last company, he was kind of the visionary. He would come up with the idea, but what if he's wrong and how do you break that to him?

Rodney Cox:

Sometimes he is wrong and you find out when a feature launches and maybe customers don't use it, but that's the beauty in being iterative is that to think that you can always be right about what the future product needs to be, it's just crazy because if Kelly were to try to build what RiskRecon is today five years ago, it would have been completely wrong and completely off because that's a Waterfall mindset, not an Agile mindset. So as we take customer feedback, we try to really leverage that in our product development. Yeah, we do get things right more often than we get them wrong, but when we get them wrong, what do we do? We reiterate and we figure out how we got it wrong and why we got it wrong and use that in the next iteration of that feature or also in any other feature. I think identifying areas where you failed and where you need to improve and using that as growth and as an indicator for an area where you need to improve as essential.

Josh Ruggles:

I mean, in those cases where maybe he or someone else had an idea and it's not checking out with what you know as an engineer and what you're seeing in terms of like the data coming in on the usage and all that stuff, how do you have those conversations? I'm just trying to figure out the process of saying no.

Rodney Cox:

In terms of correcting and learning from failures and communicating that to leadership. I have a boss. So if there is an idea that maybe didn't work out or I don't think that will work out, I don't think no is ever the answer. It's maybe we shouldn't do this and instead do this, and here's why. Because no, just no, that's a dumb excuse. If I'm just saying no, I'm not doing my job. I'm not doing the due diligence. If I'm saying no, I need to have a reason why and I need to have a solution. I need to have an alternative path. Going back to that business mindset, I think it's very important to be able to communicate why this isn't a good idea for the business, not why it isn't good for engineering or for code or for databases. Talking to a CEO and saying, hey, we actually need to restructure this database because the current one's bad, that's not a good explanation. That's not a good reason.

We need to say, hey, we're in growth mode and in one year, if we want to double our customer base, our current database schema won't hold up. We won't scale and we'll end up crashing all our systems and failing as a business. If we don't want to fail as a business, we need to take some extra time, maybe not dedicate all of our resources towards new product, new product, new feature, new feature, but instead spend some time rooting for and selling the investment on working on a backend system that needs to be overhauled because of how it will affect the business in the future.

Josh Ruggles:

I wanted to give you a chance to talk to other leaders, as well as aspiring leaders and your philosophy on how they can advance or you're looking to advance yourself.

Rodney Cox:

There is one thing that I've done really well throughout my career, and it's recruiting and it's bringing people in, talented people. And I think some advice I can give on that is always be networking and not in a vain way or like a self-serving way, but get to know people with unique skills, get to know people that are good at things, that have crafts. Build relationship with them, not just so you can hire them at some point, but so you can learn about what they're doing and so you can get ideas of things you can apply in your work. So from a leadership perspective of how to make an impact there, I think that's one area where I do have some positive advice, but I think the advice that I could give that's probably the most valuable is to those people that are young and aspiring. And I had a conversation with an individual just a few weeks ago who was given the opportunity to oversee something that was honestly out of their league.

It was something that they didn't have a lot of experience with. And I think those are golden opportunities. I look back at the early days at RiskRecon and how lucky I was to find an opportunity where I had so much learning latitude where I could learn about every part of the stack, I could build things, I could fail. In the early days at RiskRecon, there was this concept I created in my head. We were a very lean team and in the beginning, it was just Jesse and I building out all the backend systems and creating everything, and in the meantime, I'm still going to school full-time and I'm working full time. So I'm doing crazy weeks, but Jesse was just as stressed as I was and I was learning as I went. I was working on technologies I had never worked on before and so I came up with this concept of Jesse tokens. And so when Jesse tokens were tokens that I could use to go to Jesse for help. And I tried not to use more than one token a week.

I think as someone who's trying to learn and grow in their craft, I think it's very important to be very accountable and take learning opportunities as your own. And I found that I learned, I'm going to throw a number out there because it's pretty hard to quantify, but I'd say 10 times what I would have had I had someone leading me and guiding me. I was at the start of my career and if I were to go back again and give advice to classmates and friends, I would say, find the opportunity where you feel completely stretched and under-experienced or inexperienced because those are the situations that are going to force you to get experienced, force you to learn.

Josh Ruggles:

Thanks for listening to All Hands on Tech. To see the show notes and more info, visit pluralsight.com/podcast.