Skip to content
Best Practices Team Health

How CallRail Uses Developer Data Points to Drive Key Business Outcomes

It may feel like developer experience (or DevEx) is having a moment in the spotlight, recently spurring debates and think pieces galore. However, engineering professionals who have been around the block know that the concept of DevEx isn’t exactly new — investing in CI/CD pipelines and improving processes and tests are standard practices in engineering. 

So what has changed? Given the current climate of “do more with less,” we’re seeing more interest outside the engineering department in prioritizing and measuring DevEx. 

Developer experience refers to developers’ overall satisfaction and effectiveness within a company. It boils down to ensuring developers have the tools, processes, and support they need to do their jobs well. This is important because happy and empowered developers are more productive, creative, and likely to stay with their company. 

C-suite and executive stakeholder interest in DevEx — and the more productive, happier engineers it promises — has, in turn, brought DevEx front and center within many engineering departments today.

We spoke with Jellyfish DevEx customers Kristin Marsicano, Vice President of Engineering at CallRail, and Justin Kronz, Director of Engineering at CallRail, about how they approach developer experience in a way that is both data-driven and human.

Here are three recommendations around DevEx based on their experience at CallRail. 

Want more from this conversation? Watch the on-demand webinar to learn how the CallRail team approaches their developer experience. 

Translate the Long-Term Value of DevEx for Executive Stakeholders

In the wake of the pandemic, company growth and shifting economic conditions are forcing teams to do more with less. Executives are predisposed to seek ways to improve productivity and efficiency, and the demand for engineering team capacity has never been higher for most companies. 

Some executive stakeholders may require education from engineering leadership on why it’s important to “slow down” and spend valuable engineering time to address DevEx to see long-term business benefits. It’s also important to emphasize that developer productivity and satisfaction go hand in hand, Marsicano says. Focusing on productivity alone can risk damaging developer engagement and retention.

“We need to slow down to speed up,” Marsicano says. “We need to take a little bit of time to re-optimize the developer experience so that we can continue to grow quickly and get things out quickly, to be as effective and efficient, and to retain our developers because they’re happy with their workflows.” 

Align on Metrics that Make Sense to Both Engineering and Executive Stakeholders 

To gain executive buy-in on DevEx initiatives or investments, Marsicano translates operational metrics into business strategy with metrics that better align with C-suite business objectives. For example, she might use cycle time as a proxy for how quickly engineering can ship a new product to customers.

These proxy metrics empower Marsicano to have productive conversations about how certain investments may or may not move the needle on things that outside stakeholders care about — all without needing to get too in the weeds of engineering workflows or vocabulary. 

The approach demystifies the engineering process for stakeholders, transforming what used to be a mysterious “black box” into an open book. It not only makes the nuances of engineering trade-offs and strategies more accessible but also invites stakeholders to the table, offering them a platform to contribute feedback and gain insight into the workings of the project.

“If we can get alignment on one of those metrics, then it can be a proxy for us to say, ‘We do believe … if we invest in this change, take this time, spend this money on this tool or whatever, it will move the needle on this metric we’ve agreed on is important to the business and to developer experience.”

Create a Transparent Feedback Loop

One way the CallRail team is seeing success in improving the developer experience is by creating a highly transparent feedback loop. For Kronz, that looks like sharing with the engineering team what they’ve seen in Jellyfish DevEx data and surveys, sharing what they plan to prioritize and why, and following up on the results. 

“People are going to stop telling you [their pain points] if they don’t feel heard,” says Kronz. “They’re not going to bother clicking through yet another thing they have to click through if they don’t feel like it’s a dialogue that’s ongoing and … that yields some kind of change down the road.“

Kronz says maintaining a continuous and tight feedback loop not only sets expectations with the team but also builds trust and engagement. Measuring whether or not specific fixes cause measurable impact shows teams that leadership is genuinely invested in the developer experience and taking real action to address challenges. 

As feedback loops get tighter, it can also create a space where developers feel more comfortable sharing concerns before they escalate. This culture of continuous improvement can also encourage more proactive knowledge sharing amongst teams or even self-activating on specific challenges. 

Jellyfish Helps CallRail Balance Qualitative and Quantitative 

CallRail’s final piece of advice for those diving into the developer experience?

“There are tons of experts out there, don’t go it alone,” says Kronz.

Case in point: CallRail uses Jellyfish’s EMP and most recently decided to try Jellyfish DevEx. CallRail worked closely with Jellyfish to develop and deploy their first developer experience surveys. 

If you want to try out Jellyfish’s free Developer Experience product, Jellyfish DevEx, join our Beta waitlist