How to align your tech stack with your organization
November 9 2019
This article covers best practices to align your tech stack, and any new apps you acquire, with your organization, team, and current and future goals. It’s part of a larger series of articles on best practices for revenue operations, marketing operations, sales operations, and customer operations. Get more insights into operational best practices in “The professional guide to revenue operations.”
Why it’s essential to align your tech stack with your organization
As an operations professional, you know how important it is to use software that makes sense for your organization and team. Acquiring technology that isn’t a good fit for your use case or the people who need it is a recipe for a pile of software nobody uses. In addition to being a waste of time and effort, those low adoption rates can lead to low return on investment. And the low ROI leads to uncomfortable questions at the end of the quarter/year when budget leaders ask why your team is spending so much on software no one uses or isn’t creating value for the business.
Software adoption matters to businesses and frequently has a measurable effect on the bottom line. For example, research shows that sales organizations with less than 75% CRM adoption have noticeably lower win rates and quota attainment. The converse is true - higher CRM adoption leads to noticeably higher win rates and quota attainment.
Higher CRM adoption rates lead to higher sales win rates and quota attainment. Image courtesy CSO Insights
Phase I: Budget approval and planning
As we mentioned previously, an essential aspect of smoothly and efficiently implementing new technology is having (or making) friends. At a minimum, it’s worthwhile to build strong relationships with the following parties:
Your budget owner - Most of the time, your budget owner is your boss. At the risk of stating the obvious, having a good relationship with your boss will be important to get their buy-in for new technology. Depending on your situation, you may need to submit a business request that outlines your:
- Objective(s)
- Problem statement / Reason(s) for acquiring new technology
- Cost(s)
- Benefit(s) and/or saving(s)
You may also be expected to provide a full cost-benefit analysis for your next acquisition.
IT/procurement - Depending on the size and terrain of your organization, you may also have to go through IT to attain any new technology. Briefing your partners in IT on your business needs, technical needs, timeframes, and budget - as well as making arrangements to remove much of the technical lift from their shoulders as possible - will help ensure a smoother implementation.
Security + Legal - You’re already familiar with the trend toward growing data privacy regulations such as GDPR for Europe and HIPAA for healthcare. So you know it’s essential to work closely, and early, with your security and legal teams to ensure any new technology you procure complies with every InfoSec regulation your company follows before you acquire it.
Your end-user(s) - It’s also helpful to have a working relationship with end-users who are using or will use your new technology. Having a working relationship means you can partner closely on implementation and enablement, and garner early feedback on whether a new app is a good fit and will deliver value.
A note about timing - It’s also vital to be organizationally ready for new tools, particularly those that may require weeks (or months, more likely) of implementation. A best practice is planning for a sufficiently long pilot period to ensure full adoption, end-users getting over any learning curves, integrating with necessary systems in your existing stack, and collecting enough data. Plan your implementation time against quarterly/annual budgets accordingly!
“To drive ownership and ensure stakeholders have ‘skin in the game,’ consider creating a cross-functional product council.” - Dave Hsu and Emily Cnossen of SAP Concur at MarTech East 2019
Phase II: Identifying stakeholders and roles
As we’ve mentioned previously, a significant step in acquiring new technology is identifying stakeholders. These may include:
- Business champion - The original requestor of the new technology.
- Sponsor - Your budget owner
- Product manager - Yourself or a colleague who will manage procurement, implementation, and post-implementation, with an understanding of the pain of the business users well enough to map product features to business needs
- Stakeholder - Any additional stakeholders in the process
- Vendor(s) - The vendors you’re considering
Of these parties, you may find yourself working with:
- Operations - Your own team. It’s common for revenue operations to have the most insight into new technology to acquire and act as subject matter experts, enablers, and project managers for implementation.
- IT/procurement - May be involved as stakeholders to help with procurement and implementation.
- Security + Legal - Likely involved as stakeholders to help vet new technology purchases against any data security or legal issues.
- Customer experience (CX) - May be involved as advisors to help you map specific tech stack features against current or future customer initiatives.
- Additional cross-functional stakeholders - Depending on your company’s size and makeup, it may make sense to recruit other stakeholders for tech stack adoption across your organization. (See below.)
The leading cause of software project failure is changing/poorly documented requirements. Source: Statista
Phase III: Ownership, adoption, and enablement
Operations professionals know that implementation is an ongoing process that never really ends, thanks to version updates or feature releases, changing business needs, and growing teams. However, driving ownership at every step of the procurement, implementation, and adoption journey maximizes your return on investment and minimizes painful delays. Here are some tactics to ensure every stakeholder takes ownership of their role along the way:
- Clearly communicate expectations upfront - It’s essential to clarify expectations in advance with regards to roles, expectations, schedules, and scope of work. However, research shows that the leading cause of software project failures is changing or poorly documented requirements. It’s crucial to lay out a vision for your current and future tech stack as well as to communicate and document the role each stakeholder will have.
- Identify an internal owner to own KPIs - As we mentioned, organizations frequently expect their operations teams to be subject matter experts on software. However, it's often unreasonable and counterproductive to expect operations teams to own all KPIs for every app, particularly when they aren't the primary users. A best practice, whenever possible, is to identify an internal owner of any new software to own the KPIs.
- Statement of work - If applicable, consider making ownership official by issuing a statement of work to your business champion and/or technical users.
- Executive sponsorship - As you might expect, executive buy-in can also help enforce adoption.
- Consider instituting a product council - A product council consists of representatives of every major functional team in your organization to help oversee the deliberation, procurement, and adoption processes.
A note about product councils - Building a cross-functional product council can act as a forcing function that drives home the importance of making timely tech stack additions. If you’re not confident in your ability to assemble such a group, it may be worthwhile to seek executive sponsorship to get it off the ground. When the time comes to escalate the procurement of new technology or to enforce adoption of an expensive piece of software, you may find it useful to have more voices arguing for your point than just your own!
A note about enablement - As you know, once you’ve finally acquired your shiny new technology, your job isn’t over. Another critical piece of the puzzle is clear documentation to enable users and ensure they make use of their new software. However, a shared burden for operations professionals is becoming the in-house subject matter expert for troubleshooting any new software by default. Providing enablement materials can offload this burden and help your team members self-service (while you and your operations team focus on more-strategic matters).
To enable your team to self-serve, it’s a good idea to consider one or more of the following:
- Internal product training session(s) - Holding internal training session(s) is one of the most effective ways to enable internal users. It’s often a good idea to make use of your vendor’s customer success team to do the heavy lifting on such sessions. When possible, consider recording and archive training sessions for future use to enable future users.
- Internal documentation - Keeping documentation on hand, whether that includes full walk-through materials or even basic tip sheets.
- Provide a direct path to vendor support teams - It’s a good idea to remove as many barriers as possible between your technical users and your vendors’ support teams. If possible, sharing contact information and arranging account team calls directly between your team and vendors gives your users the most direct access to subject matter expertise while preventing yourself from being a bottleneck.
Takeaways
Aligning new technology with your team is arguably a never-ending process. But these best practices will ensure your current and future technology acquisitions are a good fit for your team. Get more actionable tactics on how to manage people, processes, and technology for revenue operations in these additional articles: