How Developers are Securing Buy-in Amidst Increased Scrutiny
Has the purchasing process changed in your org over the last couple of years? Are additional roles, potentially all the way up to members of the c-suite, now a part of the evaluation and/or approval stages of that process? For many, the answer is yes. And, whether your annual budget increased, decreased, or stayed the same as last year’s, developers are noticing “the business” is a lot more interested in understanding why a new purchase is necessary at this time and why it can’t wait.
It wasn’t long ago that many business leaders would’ve assumed there wasn’t much need for them to understand the specifics around a development team’s tooling needs. The assumption was generally, “As long as the CTO understands, we’re good.” When a development team expressed the need for new tooling, if the budget was there, business leaders would, to some degree, simply take their word for it.
So, what changed? Why are today’s development tooling purchase requests being put through longer diligence periods and increased scrutiny from leaders outside of the engineering world?
Today’s business leaders care about two things
In all honesty, there aren’t only two things that business leaders care about. But there are two main things…and everything else bubbles up to them. Those two things are:
- Increasing top-line growth
- Reducing costs
(For anyone saying, “What about customer experience? Our business leaders care about that!” I’m sure they do! CX also leads to greater revenue. “What about software quality? That’s really important here!” That’s great! That also leads to greater revenue and reduced costs, for that matter. I’m sticking with the “two” above. It’s not meant to belittle; it’s a compliment.)
Top-line growth and reduced costs aren’t new desires in the business world. They’ve always been important, but there are a number of contributing factors today that have moved them from “goals” to “critical requirements.” Economic downturns, stalled hiring plans, the ease of switching to competitors, and a dramatically increased cost of software failures have pressured companies to be proactive and not reactive when looking for every opportunity to reduce the risk those threats bring.
Whether your own company is facing only one or each of those threats – no company is exempt from all of them – finding ways to increase revenue and reduce costs in tandem has never been more important than it is today.
Developers who can detail to the business how new tooling contributes to accomplishing those two goals are far more likely to see their purchases ultimately approved and not added to a growing “let’s revisit this later” pile.
To get their buy-in, first give them yours
There’s a great LinkedIn article by Aline Maschke that talks about how the CFO has become an increased participant in the buying process, a role that many development teams have historically not had a ton of face-to-face time with. I love this piece of advice:
What CFOs want is for you to know the position they’re in – and to explain how you can improve it.
While this article was focused only on earning the trust and buying approval of CFOs, you can swap out CFO in the line above for any business leader and decision-maker who’s a part of the buying process in your organization. In some cases, you may even need the CEO’s buy-in.
Here’s how you increase your chances of securing the interest, trust, and buy-in from that group:
Take the lead
In some orgs, a CEO or other members of the c-suite will come to speak with the engineering department for an informal chat, or maybe an ask-me-anything. It’s great when that happens, but that’s not your once-a-year chance to speak with “the business.” Call a meeting with these people yourself. Or, if you need to go through someone else higher up than you…but not quite that high up…to make that initial request, that’s fine, too. But, given the pressure every business leader is under to be proactive, this a great opportunity for you to be the same and to show interest in their world. (Spoiler alert: There is no “their” world. Your worlds are one in the same.)
Use your natural curiosity to your advantage
Developers, testers, and every other engineering team member are, by their very nature, curious, always learning, and always looking for creative, innovative solutions to complex challenges. It just so happens that launching, maintaining, and scaling a successful software company is full of complex challenges for business leaders.
Before you ever think about pitching and/or demonstrating the value and ROI of the software tool you need, it cannot be overstated how important it is to find out what your decision-makers need. It may sound overly simplistic, but you’ll learn this by simply asking. You already know that every business leader is looking for ways to increase top-line growth and reduce costs; let them know that…and then express an interest to dive deeper with them.
For example, you might say:
“I know that it’s very important for our company to increase top-line growth while reducing costs at the same time. Can you share with me where we’ve done those two things well, and where we’ve either struggled or not yet looked into? Understanding that will help me look for ways where we on the engineering team should focus on how we can directly contribute to those efforts.”
Identify and arm your champion(s)
You might be thinking to yourself, “Your champion? This was my idea. Wouldn’t I be the champion?” You should, but you shouldn’t be the only champion. Maschke writes:
“…identify members of the buying committee that stand to win if the deal closes and turn them into champions. A champion is more than someone that lets you know what’s going on behind the scenes – they are actively advocating for your product or service when you’re not in the room…
…Coach your champion on the why. Use other employees involved in the deal to get more information on specific metrics and company initiatives…”
Why can’t you just know the convincing stories and/or metrics that support the need for new development tools by heart? Because, as Maschke writes, you might not always be in the room. Share, arm, and coach those other champions on how to connect your team’s tooling to companywide impact just as strongly as you can. You’re going to need their vocal support whether you’re in the room or not.
Your job right now is to get as much information as you can about companywide initiatives, as well as the supporting initiatives of each member of the buying committee member. They need to know that you care about (and can contribute to) those needs, too.
Welcome pushback…because you’ve planned for it
Chances are, no matter how many times you’ve rehearsed your pitch, or how buttoned up your slides look, there will be dissenting voices, tough questions, or “I don’t really get it,” indifference from some on your buying committee. Today’s buying cycles wouldn’t be longer than ever if all it took was a single meeting, or a single “yes,” to get the green light to sign a contract.
Think about it. If your company’s entire business depends on the software or digital services that your company sells, and you’re coming in with an ask for budget that changes how those products are developed, tested, or deployed – there should be pushback. Your employer would be introducing entirely too much risk to the business and to your customers if they didn’t ask questions, demand to see proof, and need to fully understand the risks of not making this new purchase.
You believe this new tooling will result in companywide benefits? Good! Make sure that you (and your champions) can explain and demonstrate how. But, just as importantly, be just as sharp at covering how it will not result in added companywide risk. There may be questions from the room that you have to go get the answers to, and that’s okay, but come ready to address concerns around risk. Those concerns will be top of mind for some in the room, so they should be top of mind for you.
In conclusion: “Visibility is viability”
I love this quote from Marie C. Wilson, so much so that it’s become a bit of a mantra of mine. There is so much going on in all of our professional lives, and we’re constantly looking for ways to improve, accelerate, and increase the efficiency of our endless workflows.
The tools you use to build the software your customers love should provide visibility throughout the SDLC into opportunities for acceleration and innovation, and just as importantly, to potential risks. While you and the engineering team might be the only ones who use these tools, it’s important for other stakeholders to understand and champion the visibility they’ll bring to your entire organization.
Returns on investment don’t become viable until they become visible. Make them so.