It’s the oldest MBA trope in the business world: “what gets measured, gets managed.”
Coined by management guru Peter Drucker long before digital experience was a thing, the concept gets tossed around the halls (and Slack rooms) of organizations large and small.
In less idiomatic terms, if you don’t have a direction for where you’re headed, you’ll likely end up somewhere you don’t like. Which is nice advice, but for dev teams and engineers, it can be a bit more complex.
When people involved with your work (executives and top management) can’t quite understand the intricacies of what you do, it gets hard to quantify and explain the benefit of your work.
If your engineering team needs to prove the tangible, financial value of its work, we have three benchmarks for you to use.
(Want to skip ahead to the details? Check out “The software engineer’s guide to Digital Experience Intelligence.”)
The amount and quality of code being shipped
One common metric by which software development teams are measured is how good and how much code is shipped—how often the work of developers sees the light of day in the products and services the company offers.
After all, when teams aren’t shipping, hard work is effectively wasted. Code that sits on the shelf for weeks or months often gathers subtle bugs, and it’s difficult for teams to jump right back into the same frame of mind they had later down the road.
At the same time, shipping not only helps products—it also helps developers themselves. When software goes out to users, feedback slowly makes its way to the development teams from product managers, helping devs hone their skills.
However, using Digital Experience Intelligence (DXI) tools such as FullStory, engineering teams can see first-hand, near-immediate end-user interaction with any new code pushes via Session Replay. While bugs are inherent, Session Replay helps dev teams narrow down on exactly what users see, and how page performance affects your customer experience.
Want to take your digital experience to the next level? Let’s chat.
Solving important user problems
So, code is being shipped, and the product is being improved. Great news!
However, is your website or app being improved for the sake of improvement, or is your work substantially minimizing the user problems teams really have?
While development roadmaps and prioritization is a hand-in-hand exercise with product management teams, it’s critical for engineers themselves to ask questions and look for a deeper “why” to any prioritization directive.
Asking questions helps dev teams become more closely aligned with users and product teams alike, and nearly always results in a better end product. Aligning the specs laid out by product teams, what users need, and what dev teams can accomplish in a set period of time helps create total transparency into the process.
The end result: resolving user problems that make a difference for the company.
What’s more, with modern DXI tools, teams can draw a line between problem identification and engineering work, indicating that your team helped solve business-critical problems.
Tying site performance and revenue impact
Let’s say you’re the manager for a web dev team that handles the website and mobile app of a major ecommerce retailer. Sizable amounts of revenue and thousands of visitors depend on the quality of your code. On occasion, small bugs pop up, and you and your team triage and correct them.
When your CTO emails you and asks for clarity around the business impact of your work, what do you tell him or her? Sure, you’re helping make the user experience stronger, but what’s the dollar amount associated with that?
A huge benefit of DXI tools such as FullStory is connecting the dots between site performance and revenue impact.
For instance, see the number of lost conversions associated with friction and frustration points, then resolve and watch quantitative impact. No more black-box revenue calculations or panicked looks when asked how your role contributes to overall company health.