Last year I got my first experience of implementing software internally. My team found a SaaS (software as a service) product they wanted to use, so we bought it and used it.
Sort of. It was NOT SO EASY.
There’s money to pay, and that has to get through several rounds of budget approvals, and negotiations with the vendor’s enterprise sales rep, and I get to talk to Finance. This is the obvious part. I thought it was the hard part. It was not.
There were security reviews to get through. That wasn’t a surprise. But then, they raise the question of whether this is a subprocessor. If it’s gonna have data about our customers in it, it counts as a subprocessor under GDPR. When we add it to our subprocessor list, we have to update this 30 days before we start putting any data into the new software. We have to actively notify some customers, and some of those must actively approve it. That’s work for Security, Customer Success, and Sales.
Then we can start getting data in. The key integration was Salesforce: who is a customer, what companies are target accounts, etc. That meant working with RevOps. (It rhymes with DevOps, but the word origin is different.) Revenue Operations people run software like Salesforce, configure it, and make a lot of reports work. They answer “Is what we’re doing working?” for Sales and related departments. Compared to DevOps, there’s a lot less version control and more digging data out of corners. Corners like that new SaaS we just bought.
There’s more data available, in more software, run by other departments, and those were each their own adventure.
Once we have our own data in there, we can use the software, right? On our team, yes. We can learn how to navigate in the software, where the useful stuff is. But this doesn’t get our company the value we promised when we convinced people to approve this budget.
The hardest part of all is integrating the software with the people in the organization. Convincing them to try it, showing them where the data is. Why would they log in to yet another system? Why would they click on new screens? Answer: they mostly won’t, and then we try giving the license to someone else who will. Taking software from new to important is an organizational feat.
Finally, don’t forget maintenance. Wait, this is SaaS, we don’t have to do maintenance on it! but we have to maintain the connection between this software and our company. This means, when someone gives us a GDPR deletion request, I get to manually remove their data. When integrations break, I have to care.
And I have to go digging in corners for data to answer: are we getting value out of this software, like we hoped to?
At the end of a year, my team member who instigated the purchase was gone; the sales rep who loved it most was gone. Only one person in Sales used it regularly, plus me irregularly. I found occasional value in the data there. It wasn’t useless. But I wasn’t even gonna try to justify the budget again, and I never want to be pulled into a twenty-person GDPR deletion thread.
Buying enterprise SaaS is an undertaking, implementing it is a project, and integrating it into habits is an Initiative (with a capital I).
As a software developer, this gives me a perspective of how much work happens after the code is written and deployed. The goal of software development is to provide useful capabilities to customers. Those capabilities don’t exist until the software is running in production; they aren’t useful until many people do the political, technical, and social work of integrating the software into the customer’s existing systems.
Meanwhile, my job now is about getting our SaaS into companies where people can use it. Ours has more depth of software integration, plus more breadth in who can use it, and proffers a new philosophy of software operation and development. It’s a much bigger change than the one we tried last year. Helping our customers succeed at this is super interesting work.