Q&A with James LaPlaine, CTO of Red Ventures

If you ask James LaPlaine how he got here, he’ll tell you that he’s always been curious, even at a young age. This curiosity led him to computing. After running a popular dial-up bulletin board system from his bedroom in high school, he naturally pursued a degree in Computer Science, which allowed him to be present at many historic moments of internet history: running the systems for NORAD Tracks Santa, The Grammy’s, and the Lord of the Rings movies; setting video streaming records during the first season of Big Brother; shuttering Netscape; dozens of acquisitions and secret diligences that never panned out; AOL buying Time Warner, unraveling, and eventually selling AOL to Verizon, and then buying Yahoo.

Today, James is the Chief Technology Officer for Red Ventures, a private digital marketing firm that owns a portfolio of digital assets including Bankrate, HealthLine, Lonely Planet, and CNET Media Group. He’ll proudly describe the impact of their technology platforms and data science models, yet his greatest accomplishment at Red Ventures has been cultural, not technical: building a thriving community of technical teams that will long outlast his tenure. In a collaborative, rather than competitive, atmosphere, he proudly oversees the benefits of an inclusive workforce, and nourishes curiosity in pursuit of great solutions.

What has been one of your greatest successes or something you’re most proud of as an engineering leader?

Over the past few years, my work at Red Ventures has moved small engineering teams into a thriving community of technologists. I found that smaller teams were often myopically focused on the work at hand, with little cross-team connection. Now, our engineers keep their focus on specific business deliverables—but they are more engaged with sharing their approach and technologies with others. We are more readily drawing inspiration from other teams, molding and adapting techniques and methodologies to sit within a team’s unique culture.

What has been one of your greatest challenges as an engineering leader over your career? Or, what keeps you up at night currently as an engineering leader?

There are two challenges, which I believe go hand in hand. First, engineers love to build anew. If the requirements and scope are not well-defined (and kept in check throughout the process with effective ceremonies), they tend to overcomplicate the end solution. Second, our technology teams are not natural marketers and often fail to be great at providing a narrative, in non-technical terms, that informs others what they are up to.

When combined, a solution may miss the mark in terms of features, performance, or scope. It may carry enough complications that it hastens the onset of technical debt. We strive to combat these challenges by bringing in engineers earlier in the design process; defining smaller, iterative bits of work that can be managed to celebrate simplicity; and favoring buying or integrating over building unless the capability is a significant market differentiator for us.

How would you define engineering effectiveness?

There are several dimensions to engineering effectiveness:

• Code quality
• Ability of the feature to meet business requirements
• Ease (and automation) of deployment
• Reusability, in two ways: Can this be reused elsewhere? Did this reuse components from others?
• Alignment of task and position. Did the appropriate level engineer work on this project? Is staffing meeting assignment needs?
• Estimated versus actual time of work completion
• Appropriate complexity and documentation

What are some signals you use to know that your team is effective?

We’re big fans of Accelerate: The Science of Lean Software and DevOps. In fact, we believe so strongly in it that we give a copy of this book to every engineer on Day 1. The book outlines four key metrics for high-performing engineering teams:

1. Delivery lead times
2. Deployment frequency
3. Mean time to repair
4. Change fail percentage

What’s your best advice for an engineer being promoted into their first management role?

If you’re being promoted from engineer to manager of your team, this is one of the hardest transitions to make. The people who were your peers are now your employees. It will be important to establish the new norms and not assume that the relationships you had will remain the same.

Oftentimes, the best engineers are selected to become people leaders (this isn’t always the best choice), which can leave a gap on the team. While our engineering managers still have some direct coding responsibility, they are not simply adding people management on top of the heavy workload of a senior engineer—and striking this balance is important. Working out the new team capacity and staffing requirements will be an early task to manage.

My advice: Find a mentor that has made the same transition. Build your network of trusted sources that can help you navigate the transition and give you a thought partner. You can no longer have the same level of candid discussions with your direct reports as you did as their peer. You carry more responsibility and have to represent the corporate interests in new ways.

As you think of your role in aligning to business objectives, what have you found most helpful in communicating risk or status upwards?

First and foremost, you must establish a rapport with the non-technical leaders. I feel I most often play the role of translator, deciphering technology jargon into terms that support our business outcomes. It’s reciprocal—I am always looking for the context I can glean from non-technical business leaders to bring back to my team as context for the work we are doing.

One of the hardest jobs is estimating how long something will take to complete when you have never done that work before. Be careful when committing to a timeline where there is high uncertainty. Set the right expectations that you are providing estimates and will consistently update and revise these estimates as the team learns more and makes progress. Don’t sandbag (i.e. lower expectations), and be honest about unexpected obstacles and missteps. This will build trust that will serve you well when something unplanned comes along.

What early warning signs do you look for to know that your deliverables aren’t on track?

During stand-ups, we listen for language that indicates someone is blocked or waiting on a dependency. The frequency with which these blockers arise can be a good indicator of slippage. Another warning sign is scope creep, which can endanger both the timeline and introduce ambiguities about the previously established priorities and focus. The other side of that coin is unclear requirements, which can indicate that our direction lacks conviction or stakeholder support. That lack of engagement or feedback from stakeholders can indicate that their needs have shifted, or that the priority may need to be reevaluated.

Have you set goals or used data to manage your organization that turned out to be ineffective? Why?

We attempted to use story points to help quantify the software development activities that could be capitalized. This proved to be far more cumbersome than asking the engineers to simply capture the time they spend on capitalizable activities.

We have also reported the types of activity that engineers are spending time on, narrowing our categories down to activities like bug fixes, feature work, operational tasks, technical debt, and research. While the data is interesting, it has not yet shifted much of the behavior of teams. Our hope had been that if we tracked activity in this way, we would bring awareness to where we have an imbalance (such as bug activity and code quality).

Given a much greater WFH culture due to Covid, when you look forward over the next 5-10 years, what skills, tools, data, etc. will managers and leaders have to master to be effective leaders?

Communication will continue to be the most important element to coordinate priorities and conduct resource planning. The impacts of COVID have shown that we have improved productivity by eliminating office-based interruptions. Instead, we have had to rely more on communicating our workload and progress. When we cannot simply observe what others are working on, it is critical that we set expectations for deliverables, share when we’ve hit a roadblock, and know enough about what others are working on that we can draw inspiration or offer help. And bringing someone new into a team is harder when everyone is remote or separate. Using tools that support peer programming is one way to help overcome the absences of being together.

I am hopeful that advancements in video conferencing tools and virtual whiteboards will help us in the future. We may be in for another inflection point as we enter a more hybrid office environment, where our teams are mixed between the office and home. There’s a loss of an even playing field—when we were all remote, we were equally connected and disconnected—so keeping information flowing evenly will be a new challenge for us all to tackle.