Illustration by Matt Peet

Rodney Cox is young, ambitious and has cut out a successful career by exceeding expectations whenever presented. He’s grown accustomed to putting himself into positions where he feels the pressure. To Rodney, being uncomfortable is where he’s comfortable. This is where he thrives.

“I think in your career, you should strive to be an impostor,” Rodney says. “Those are the situations where you're going to be in hot water. And when you're in hot water, that's when you're learning. I find that that's where the most growth is.”

Newly minted VP of Engineering at mobile ecommerce start-up Via, he’s placed himself into one of the most stressful positions in the tech sector. A lot is riding on his abilities. But if history is any indicator, he’s got the chops to convert the pressure of leadership into something big. Rodney was initially headed for a business administration degree until he saw coding as a better way to address the technical problems he wanted to solve. Starting his career by co-founding two tech projects while still in college, he quickly joined cybersecurity start-up RiskRecon as a founding engineer. Within five years he was one of the key leaders on an engineering force of 30 as manager of software engineering and head of internal tools. This type of growth in his role and responsibilities was not an accident. He wields a rare combination of technical problem solving, business acumen, the humility to lead and he’s brimming with gritty work ethic. 

As his former boss and CEO of Risk Recon, Kelly White wrote in their company blog, “As the company grew, Rodney went on to build and lead teams in building the systems and algorithms that were core to RiskRecon,” he recalls. “Rodney gained a rapid acquisition of skill, teamwork, leadership and proof to himself that he could do big things. And Rodney built the foundations of what would become a successful company.”

Now Rodney’s moved to the next phase of leadership that offers him a similar challenge, but with the new ability to create his own roadmap.

As he ramps up his team, Rodney offers the teambuilding philosophies and personal growth strategies that he developed and deployed while in the rapidly scaling environment of his last team leadership role. But because he’s starting from scratch at a new start-up, he understands the challenges ahead, and anticipates learning a lot in the coming months and years. 

“If we were to have this conversation in four years,” he says, “I’d probably have a playbook. This is what I would do, this is what I wouldn’t do, this is what I did and this is what I learned from it.” 

Sitting down with Rodney, he breaks down how a business-centric mindset guides the product roadmap, his approach for keeping processes lean to facilitate sustainable growth and how he has come to believe impostor syndrome is actually an ally for improving his own abilities. Finally, he expounds on how the right people matter more than the right processes—what traits to look for in team members, how to keep them motivated and learning, how to structure a team to maximize everyone’s contributions and how to diagnose a team when things aren’t working right.

Impostor syndrome is, essentially, the feeling that you are pretending to know more than you do. We usually see it as something to struggle against. Rodney, however, throws his arms around it and actually seeks out situations where he feels the uncomfortable feeling of being in over his head. Because being in over your head means you have to swim for survival.

His philosophy is, essentially, get yourself into situations where you feel like an impostor. Do it strictly because it’s uncomfortable, difficult and new.

He points to his five years helping take RiskRecon from a startup through its acquisition by Mastercard. “If you had told me that first year the things I would have to accomplish by my last year, it would have been a nightmare,” he says. “I wouldn’t have ever envisioned myself being able to build data models to scale systems. We went from monitoring forty-some thousand companies at the end of 2019 to monitoring 4.5 million by the end of 2020. I would have never foreseen myself doing that. But because I was constantly finding areas where I could be an impostor, it forced me to grow, forced me to learn until I got to a point where I was able to do hard things.”

While he relishes being an impostor, Rodney thinks perhaps we should do away with the term impostor syndrome. Instead, we could say that we are in growth situations. 

“If I had looked at that from the view of I’m an impostor, I wouldn’t have been successful,” he says. “I saw my deficiencies, and they helped me know where I needed to learn and grow.”

This is a two-step equation. It’s not enough to make yourself uncomfortable; you actually have to own the initiative to develop and improve. Rodney says this holds true at every level in an organization, and in every role.

“As someone who's trying to learn and grow in their craft, I think it's important to be accountable and take learning opportunities as your own,” he says.

That may mean turning away from the easy ways out. Rodney intentionally self-limited the times he could ask for help while starting out as a founding engineer, because even though assistance might get the job done quicker, he wouldn’t learn as much. He forced himself to stay uncomfortable (to a point)—because the latitude to learn is the golden opportunity.

Coming into a role as an impostor (ahem—with a growth situation), Rodney finds it helpful to have a high-level guiding light. He may know little about the task at hand, but he knows why that task matters—and that knowledge helps him steer decisions from the start.

“One thing that has set me apart in my ability to add value to the business is being able to understand the balance between technology needs and business requirements,” he says. “It comes down to being an advocate for the business.”

Rodney describes his approach as business first, technology second. After all, the reason we have jobs writing code and leading development teams is so that the company can make a profit. So he roots all the decisions he makes as a tech leader in how it benefits the business.

That’s why he stresses starting with a lean process as a general rule.

“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 as competitors are developed,” Rodney says. “They're winning more deals, you're losing them. I definitely think it’s smart to stay lean on processes until you realize they need to be added.”

This strategy plays into the growth-mindset: heavier processes, such as we often see with Waterfall, are ultimately grounded in trying to predict and control the future; whereas Agile processes intend to identify changes that need to happen, and to iterate quickly. It’s built for those willing to accept that there are things they don’t know, and that unanticipated change is inevitable.

Rodney’s experience is that the latter is better business. “The damage from lightweight processes, from not being robust enough, is easier to mitigate than the cost of being slow and becoming irrelevant,” he says.

Over time, that balance will shift. “The cadence of iterations as the business matures will decrease because you’ll get in a groove and your team will create a culture and an identity,” Rodney says. “It’ll help you hire the right engineers that fit that culture. And you’ll end up with a good tech team.”

Another reason Rodney recommends keeping process lean at the start is that the right people will create the right process—not the other way around. So you’ve got to start finding the right people before the structure of the team or organization can develop.

“I'm holding off on implementing anything until I bring in additional people who I know I can trust and rely on,” he says. “I want their insights as well, because my process might not be the best for them. That way we can come up with some sort of hybrid model that works the best for this team. Although my experiences are valuable, if I was to just implement everything my way right now, it wouldn't be right-sized, it wouldn't be calibrated. And it would become toxic.”

The clear key here is to find—and hire—the right people. Rodney describes these as talented people with unique skills, people who are good at their craft, and people with whom you can build relationships. Even if you don’t hire them, you can still learn from them and apply ideas to your own work.

Rodney doesn’t like the idea of hiring people based on the coding languages they know or the frameworks they’re familiar with. People can learn those skills. Instead, he looks for people who take ownership. People who are passionate and curious. People he can trust to learn and grow and do quality work.

Then he winds them up and lets them rip.

“Micromanaging is really bad from an engineering perspective,” he says. “The whole concept of software engineering, of innovation, is abstract. Hovering and giving specific instructions essentially removes the engineering component from the work. And people become engineers because they want to engineer things. Strip them of that, and they will become disinterested.”

He maintains a hands-off approach, but not a low-touch one. He recommends you hold weekly calibration sessions that are more about How do you feel about how things are going? What do you need? How can I help you? and less about Here’s how your performance grades out. 

“Those kinds of questions are the way that you really help someone develop and grow,” he says. “The result of that is more conviction, better products, better outcomes and more winning in business.”

“A culture of recognition and accomplishment is very important across every facet of an engineering team,” Rodney says.

Engineers are inherently creative people. He recently read the book Ask Your Developer by Twilio CEO Jeff Lawson, which raises the point that developers aren’t merely good at math and doing repetitive tasks—the bulk of them play music, or are photographers and videographers, or mountain bike, or lift. Surprise! Their interests are as diverse as anyone else’s, and they express themselves through different forms of creation.

“One thing that all creators care about is their work being valued,” Rodney says. “Everyone wants to be valued and recognized. So it’s really important to me to broadly broadcast people's successes.”

You can do this in all the usual ways, but one overlooked one that Rodney emphasizes is to single out individual accomplishments instead of always folding them into the team’s success. At a company all-hands, for instance, you can go beyond what your team did to point out individual developer’s contributions.

Just like process, Rodney aims to keep structure lean and effective—especially starting out. He borrows certain ideas from the military, which has a long and vested interest in things going well in a variety of circumstances.

• Appoint lieutenants. Rodney recommends hiring a small number of people (say, two) who you really believe in. He calls them lieutenants because they really are operational extensions of his leadership style. He wants people who agree with his business-first, technology-second mindset and who have strong cross-functional understanding. “I want someone who's very good at front end, who understands product design, everything from thinking through the user stories, spec’ing it out, knowing project management really well, and how to divvy out tasks,” he says. “And then someone from a backend perspective who knows how to scale back-end systems. Knowing that both of these individuals will be business-minded will ensure that we have the right parts of the technology covered, and also that we're covering them from the right approach.”

• Build squadrons. The ideal team size is one of the enduring questions of tech leadership. Rather than splitting up front-end and back-end developers, Rodney finds that micro-teams of four cross-functional members (with two from each end) work most effectively. “We can break up features that are requested into a bite-sized feature, give it to four people and know they can do everything from design to delivery,” he says. 

• Stack teams, and communicate with all levels. You can envision a scaling team in a pyramid shape—but Rodney dislikes the pyramid pitfall of middle management. Whereas a lot of tech leaders try to leave coding entirely to the developers, Rodney goes against that grain and believes leaders should still get their hands dirty. “I think it’s important to be on the ground floor and see what the ‘troops’ are seeing,” he says. “At each level, there is still a hands-on approach and a heavy involvement in the development of the product.”

That goes for him as the team lead, and for his lieutenants. Naturally, those leadership roles will grow more removed from the ground-level as the team scales. Rodney acknowledges that the parts of the work he and the lieutenants might do will slowly silo. Their involvement will become more big-vision items.

Speaking of scaling teams—by hiring passionate people, you will also have a team of people interested in advancing their careers. Too often, the only path for advancement is management. 

“If engineering was about becoming a leader, you wouldn't have a successful engineering team because everyone would just want to manage people,” Rodney says. “You need people that are extremely passionate about writing great code and continuously learning.”

So he recommends establishing different growth paths. Looking at the pyramid structure, someone at the bottom level does not have to be at the bottom compensation level, too. Growth is about taking on greater roles for the business—not about climbing a ladder.

“As these individuals who don’t have interest in leadership learn and grow in your organization, you grow them laterally by giving them more responsibility in terms of architecture and algorithms and systems design,” Rodney says. “That has nothing to do with people management and everything to do with the longevity of your product.”

Establish a leadership path and an engineering path. Make sure they match in compensation, growth opportunities and respect. Yes, putting passionate engineers in a leadership position might stick them in a growth scenario—but if leading people is something they have no interest in learning, it won’t be a fruitful challenge for them.

Success doesn’t always happen. If you’ve hired passionate, curious, creative developers, the odds are not that you hired the wrong person—but that you put them in the wrong role.

“Maybe it’s something they’re not passionate about,” Rodney says. “How can you restructure the team to get them on projects that get them excited and engaged? That’s a problem you can fix.”

Where he sees it getting more complicated is when a developer is genuinely uninterested in the business’s success as a whole. They’re disconnected from that primary guiding light, the reason the job exists in the first place.

“Those are tougher conversations,” he says. “Not in a punitive way. But look, we want them to be successful. This is what we need. How can we help them get there? Ask them what project you can get them on, or what changes in their responsibilities you can make to make sure they feel like they’re learning, growing and engaged.”

Every tech leader has high expectations built into their role. A lot is demanded of them from the jump and there is little room for error. This is Rodney Cox’s actionable advice on how to set yourself up for agility and growth in a tech leadership position from Day One:

• Flip imposter syndrom on its head. The scenarios where you are out of your league are the ones where you have the most to learn. So stretch yourself beyond what you comfortably know—and do it on a regular basis.

• Business-minded developing = lean processes implementation. You can create the most innovative tech on the planet, but you’ll be out of a job if it doesn’t make money for the business. Keeping processes lean keeps a team nimble and ready to pivot when things change, especially in a new or small team. The same goes for keeping team structures lean, too.

• Focus on the right people before righting the process. Hire passionate, curious developers, and you’ll find the right processes to suit them. Rodney stresses the importance of engineers doing engineering—solving problems creatively rather than prescriptively—and of recognizing and valuing their creativity.

• Make multiple growth paths available, so that amazing developers aren’t forced into people leadership roles in order to grow their careers, and people interested in management aren’t stuck in development.

This all comes down to one principle: you can’t be an expert in something before you do it. So put yourself in positions to learn, and establish everything around you in a way that facilitates your quickest, most powerful growth.

“Find the opportunity where you feel completely stretched and under-experienced or inexperienced,” Rodney says. “Because those are the situations that are going to force you to get experienced.”