The Secret to DevEx: It’s better to whole-ass one thing than half-ass two
January 24, 2024
with
Kenneth Rose
Laura Tacho, CTO of DX, breaks down where measuring developer productivity falls short and shares how organizations should aim to balance making decisions based on both quantitative and qualitative data, how to avoid misalignment with leadership, and improve company culture.
Episode details
We sat down with Laura Tacho, CTO of DX, to break down where measuring developer productivity falls short. Laura shares how organizations should aim to balance making decisions based on both quantitative and qualitative data. Humans are not machines and numbers only go so far. She goes further and encourages companies to collect accurate qualitative data, avoid misalignment with leadership, and improve company culture.
Join us as we discuss:
Understanding the ‘Why’ behind your metrics
A framework for balancing quantitative and qualitative data
Using metrics that best fit your current status (probably not just DORA)
Strike a balance between qualitative and quantitative
The changes needed to improve engineering culture, productivity, and performance aren’t happening in a slide deck handed down from an executive team at an all-hands meeting, Laura says. The people actually impacted by the outcomes of productivity metrics need to understand the objectives and buy-in — and the best way to do that is to make sure they’re listened to.
“My advice is always to start with a survey or to start with some mechanism that encourages a dialogue,” she added. “Your team goes through the pain points and friction points every day, multiple times a day.”
This, she says, is an excellent example of data relevant to productivity metrics that isn’t quantitative. The feedback from this survey is going to contain anecdotal evidence that can’t be drilled down into numbers but is no more or less important.
“I think we as leaders don’t always really take time to document and classify the feedback we’ve gotten,” she says. “That’s the important piece because you need to be able to categorize, correlate and track sentiment over time.”
All data is data, not only the hard numbers from an API, Laura says. If organizations really want to talk about being data-driven, it’s worth taking a long hard look at what data is actively being considered when making important decisions.
“We have so much research that’s been reproduced at many different companies that shows us that perception data is equally as important and powerful when paired with quantitative data,” she says. “To be a truly data-informed organization, we have to look at all the data, not just the data you think is trustworthy because it’s coming from a machine and not a human being.”
Collecting productivity data must have a purpose
When it comes to collecting productivity data, where do you even start?
Per Laura, some questions to ask yourself while trying to collect data that’s actually useful include:
Are we collecting metrics to make sure we remain high-performing or because we’re not performing well?
What does the C suite define as “performance?”
What is the company’s definition of “productivity,” and is it a definition the engineering team operates under?
At this moment in the market, Laura has found that productivity — or, at least, the appearance of it — has a lot to do with everything from headcount increases or decreases to an ongoing push for output that can burn engineers out. That’s why, in the work she does, she prioritizes a simple mantra:
Whole-ass one thing, don’t half-ass two
Seeing a bunch of projects in progress is a great indicator of productivity, right? There are multiple projects assigned to multiple people, so surely the work is getting done!
It might…but at what cost?
“I’m a big proponent of Ron Swanson’s declaration that it’s better to whole-ass one thing than half-ass two things,” she says. “One of the common threads I see across all the different teams I’ve encountered is there’s too much context-switching and too-high cognitive load interruptions. All of that is pretty much stemming from too much work in progress.”
Whole-assing the one thing, is actually a better model for productivity, she says. If organizations truly want to maximize their productivity, they need to start by understanding what is actually actively helpful to engineers and the work they’re executing day in and day out.
Interested in learning more? Listen to our full discussion with Laura, where we take a deep dive into how organizations should balance making decisions based on human-centric data and more. Listen on Apple Podcasts, Spotify, or your favorite podcast player.
Meet your host
Kenneth Rose
Kenneth (Ken) Rose is the CTO and Co-Founder of OpsLevel. Ken has spent over 15 years scaling engineering teams as an early engineer at PagerDuty and Shopify. Having in-the-trenches experience has allowed Ken a unique perspective on how some of the best teams are built and scaled and lends this viewpoint to building products for OpsLevel, a service ownership platform built to turn chaos into consistency for engineering leaders.
By using this website, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Data Processing Agreement for more information.