May 08, 2024
Marc Andreessen declared that software was eating the world back in 2011, but today, many engineering and business leaders worry about how software is eating the budget.
Years ago, software and technology departments were considered cost centers, and businesses budgeted around that. Now, after the rise of software and engineering-led companies, many organizations have recognized that software can be a profit center.
With the end of zero interest rate policies (ZIRP), businesses are under even more pressure to fine-tune their budgets, and engineering leaders are under pressure to communicate their teams’ impact. Despite this, many engineering leaders struggle to articulate the business impact of engineering.
Vijay Venkatesh, CTO at Bluesight; Alex Callihan, SVP of Engineering at KnowBe4; and Nitin Shingate, CTO at GoodRx, sat down with Ryan Kuchova, our Head of Customer Strategy, to discuss the gap between engineering leaders and business leaders when it comes to talking about the business impact of engineering.
To hear from them, check out the webinar or read on to see their strategies for effective communication.
Software Estimation Is a Wicked Problem
The communication gap between business leaders and engineering leaders tends to open up early and fast because business leaders, not unreasonably, tend to assume software development is a “tamed problem.”
Business leaders often think that software teams produce impact like a manufacturing plant – taking material input on one end and creating value on the other end. Building software, however, is decidedly wicked and iterative, meaning estimation is almost always difficult.
Estimation – known to be hard by engineering leaders and assumed to be doable by some business leaders – generates core questions that divide those leaders against each other.
For example, Venkatesh says software development always involves some “emergent properties.” In software, he argues, “We uniquely have to deal with things that are relatively unknowable at the start of a quarter and then account for them midway.”
Callihan agreed, saying, “Engineering is a bit of controlled chaos, sometimes uncontrolled.” In years past, engineering leaders were primarily defensive – often unable to communicate impact and frequently trying to protect their budgets instead of advocating for them. Now, engineering leaders can take a proactive role in controlling chaos and communicating business impact.
3 Strategies for Communicating Business Impact
During the webinar, the three leaders shared compelling strategies for communicating business impact to non-technical stakeholders. Here, we’ll highlight three strategies that capture three types of communicative work: translation, prediction, and elevation.
1. Translate Technical Debt into Customer Impact
Definitions vary, but technical debt generally refers to the cruft that builds up naturally and inevitably over time as development teams build and iterate. After a long enough time, developers may spend more and more hours managing technical debt instead of building new features (a 2018 Stripe study found, for example, that the average developer spends 13.5 hours addressing technical debt).
Despite this time sink, it can be difficult for engineering leaders to communicate why it’s essential that developers shift — even temporarily — from building new features to work that appears to be mere clean-up.
“So much of your work is strategic roadmap work,” Callihan explains. The focus naturally points to “customer-driven requirements, and the technical debt lays to the wayside of the innovations.” Over time, however, technical debt can severely damage companies’ ability to deliver the strategic roadmap work they were focused on.
Callihan compares technical debt to a “black box.” The work itself is often deeply technical and hard for non-technical leaders to understand, but the impact of fixing it is more obscure. That’s why Venkatesh advises engineering leaders to focus on translation and turning technical details into customer-facing impacts.
Venkatesh explains that the more you can make the customer impact “front and center,” the more you can connect the dots.
Shengate emphasized storytelling to accomplish this: “It’s important for us to tell the story on that — why is tech debt important? Yes, the product is important, too. But if you want to scale the business, you need high productivity. You want your availability to be 99.99%. You need to work on scalability.”
The storytelling only strengthens when you have the tools to support your narrative. Shengate, for example, explained how, in the last two or three quarters, they’ve used Jellyfish to communicate the benefits of addressing tech debt. With Jellyfish quantifying and visualizing results, the work “gives me a lot of confidence that these teams, quarter over quarter or month or month, are making progress.”
“Tying impacts, picking disparate threads, and weaving them together is a craft we need to build,” Venkatesh says.
2. Predict With Confident Humility
Often, engineering leaders find themselves stuck in a false binary: Predict with confidence (and risk missing deadlines) or hedge their bets (and risk fostering skepticism among business leaders).
Our participants explained, however, that the way out is through — by making predictions that account for uncertainty, engineering leaders can communicate confidence without false expectations.
To explain how this works, Venkatesh introduced the concept of the “cone of uncertainty.” Captured in the image below, the cone of uncertainty visualizes how project predictions become more accurate as a project progresses.
(Source)
At the outset, the scope is hard to predict, but as teams define the product, work out requirements, and begin making design decisions, predictions improve, and confidence strengthens. With mental models like these, you can explain – with confidence – why your predictions will improve over time.
Callihan adds to this idea, saying, “The hardest part is that initial forecast.” But if you can communicate in a confident and careful way, you can create a level of transparency that inspires trust despite the possibility of revisions.
Eventually, you can build and maintain transparency that inspires trust. After that initial forecast is predicted and put into practice, you can draw on it (and the following forecasts) as examples.
3. Communicate Engineering Problems in Business Terms
Engineering leaders are often middlemen between development teams and business leaders, passing messages up about what the development teams need and passing messages down about what the development teams need to do. One of the most effective strategies for improving communication is for engineering leaders to learn to speak in business terms.
For Callihan, a big part of this work was learning to set goals, communicate them to stakeholders, and drive teams in those directions. “If we’re actively planning Q4,” he said, as an example, then they can communicate, “this is where our work is going to go, meaning we have a little bit more control over where it’s coming from and where we’re headed.” Callihan says once you get a handle on it, “It’s not rocket science. It’s just labeling your work before the work even starts.”
Shingate highlighted CapEx, a concept clear to business leaders but often muddled in technical discussions. Before Jellyfish, Shingate’s team used spreadsheets to track CapEx and OpEx. As a result, the results were not, in Shingate’s words, “scientifically correct.”
With Jellyfish, his team “was able to save a substantial amount in CapEx because we were able to actually capture, from JIRA tickets, how many people were committing, what kind of research work they were doing, and what kind of new innovation was getting done.”
All three of our experts showed that with clarity from Jellyfish and other tooling, they could better communicate technical needs in business terms to the stakeholders who needed to know. Ultimately, the goal was to maintain alignment rather than turn business leaders into technical experts or engineers into business people. Improving their communication ability allowed them to cross the bridge.
Maintaining the Bridge
Like bridges in the physical world, the communicative bridges that teams and leaders build are only effective if maintained. All too often, engineering leaders have a connection to the business side, but the connection frays over time.
The tips offered by the engineering leaders we spoke to are effective today, but the greatest return on investment is when you put this advice into regular practice. As you maintain the bridge, stakeholders get more comfortable using it and crossing it, and eventually, it can be a powerful throughway for all kinds of communicative traffic.
With Jellyfish, teams can build a strong bridge and have a single pane of glass to see all the ways to maintain and improve it.
To hear more from these engineering leaders, watch the entire on-demand webinar.
