System administration seems to become a sticky topic for companies that are well into their growth phase and are pushing beyond 150 employees. The sales organization is mature, they have enough customers to justify a large customer success team, and marketing is more focused on demand generation tactics than redesigning the corporate website (again).
Improperly monitored systems can present security risks for organizations. Users are often the source of breaches. They can fall victim to a phishing scam, use poor password management, or do some damage as a disgruntled ex-employee if you're not on top of user administration (or have a gap in your communication with human resources). An information technology department focusing on security may give more priority to monitoring usage (and have better access to human resources info).
It's essential to weigh the pros and cons of different administration models and commit to more rigorous administration practices or less control over the systems the teams you support use.
System administration models don’t have to be all or nothing. There are flavors in between, and some tasks may remain with your department despite a centralized model.
Centralized administration can look different from organization to organization. Some organizations don't want people in various departments to have any administrative rights, even in a sandbox. Others manage systems purchases, renewals, and production administration while allowing operations to run point on major projects and configure changes in a sandbox environment.
It's important to determine whether the IT department is dedicating a headcount to work with your organization on projects with locked down systems. In that case, they should have a dotted line to the department manager. You'll also need to argue to retain some administrative access to auxiliary systems. For instance, it may not make sense to rely on an IT admin to make changes to a Drift workstream, sales plays in Outreach, or direct mail campaigns in Sendoso. These changes don't touch central systems of record and may be up for negotiation.
In a centralized administration model, best practices (particularly security-related best practices) are more rigorously adhered to. However, because the system administrator does not sit with the people who use the system, take extra steps to ensure the administrator helping your team is familiar with the workflows people who use the system run through frequently. Required fields and validation rules may fulfill a reporting requirement but put the group using the object over the edge if there are already fifteen other fields required.
ProTip: Do Not hire a system administrator in revenue operations until you are clear on what your team is and isn't allowed to do. Be certain to share those restrictions with anyone interviewing to ensure they'll be happy in a reduced administration position.
Decentralized administration allows departments to have unrestricted access to the systems they use and determine how they are protected. It may go a step further in some revenue operations teams who divvy up functions by supported department rather than by operational function.
There may be a Salesforce administrator who supports sales and marketing, and then another system administrator who supports customer success because of the volume of requests. You may also opt to have a revenue operations systems team with multiple administrators assigned to projects based on the level of complexity they can tackle.
If your company elects to have a decentralized model, it’s important that each administrator understands how the systems they support impact upstream and downstream technology. For example, ripping out a campaign attribution tool that also handles lead routing would negatively impact the sales team downstream if alternative processes are not developed and implemented first.
Team members who specialize in sales workflows will have an easier time navigating requests to update these processes and understand the reporting impacts. This may make sense, particularly for organizations that use separate systems per supported department (you may need an Eloqua expert for marketing, a Salesforce expert for sales, and a Zendesk expert for customer success).
However, teams who don’t specialize in a single team’s workflows may have a higher-level understanding of the broader organization. For example, if multiple salesforce administrators support marketing, sales, and customer success, they’ll share knowledge across the team and may quickly realize if a change will impact another department.
ProTip: If there are multiple system administrators in any given system, they should regularly discuss their projects. This is particularly crucial if the project spans objects that multiple teams touch. If the change is cross-functional, the project team should reflect this as well.
Bonus ProTip: If you have multiple administrators in the same system, weigh whether you want them to specialize in a particular department's workflow. They'll naturally gravitate toward the work they're comfortable with if you don't push them to go outside of their comfort zone.
In a delegated administration model, IT is ultimately responsible for managing and maintaining systems with a focus on security. They often are the sole keepers of user administration, permission sets, sharing rules, and integrations and must sign off on major purchase decisions. Other departments are allowed to have designated experts who have restricted administrative access.
For example, the IT department may be responsible for shared objects but allow unrestricted changes in objects that are “owned” by a department or record types that are “owned by a department.” In a company using Salesforce across multiple departments:
Some organizations will allow delegated administrators full administrative access in a sandbox environment for configuration and testing. This allows delegated administrators to take on the heavy lift of developing a process with flows and testing and then transferring the project to the IT administrator to put in production.
If you want to collect meaningful data, your focus should be on building a system that actually offers value to the end-user. The platform should make it easier for people to do their jobs. If not, they’re merely doing the bare minimum to meet a job requirement.
Whoever manages your systems should be empathetic towards whoever is using it. They should understand whether the team is on the road full time or dealing with a heavy workload before constructing a multi-screen process. Even revenue operations professionals sometimes lose sight of the need to balance system usability and management’s reporting demands.
Of course, we should care about metrics. Just don’t forget that user adoption is essential for data collection.
Before you commit to a new administrative model, weigh how essential the following factors are to supporting sales, marketing, and customer support.
If you're an agile organization used to changing things frequently, you'll want to retain some administrative rights. If your processes are well established, and you can envision sticking to a monthly or quarterly project cadence without much heartburn, less administrative rights may be a good thing. It may free up headcount to focus on things like analytics, commission plans, and breaking down silos.
While you're building out an administrative model, take into account auxiliary systems like chatbots, sales prospecting tools, third-party data sources, digital marketing tools, and direct mail add-ons. If you have a centralized administration model, it may make sense for IT to own the technical review prior to purchasing and integrating the systems. It probably won't make sense for them to own a lot of the workflows.
In examples given earlier, I mentioned Outreach and chatbots. This is because the workflows change frequently, and these changes aren’t integrated with the main systems. Outreach playbooks may generate emails and tasks that ultimately end up in Salesforce, but the structure of the workflow and email content shouldn’t live with IT. Chatbots allow for decision trees and data collection prior to a person being connected with an agent. Very little of this (if any) is logged in Salesforce.
If you’re giving up any administrative rights, make sure to be very detailed about what you’ll be keeping.
As someone who has seen consolidated, delegated, and decentralized administration models work well and fail, I can tell you the key to success in any model is how well departments work together.
Transparency, a shared sense of ownership (non-proprietary attitude), and flexibility have always struck me as more valuable than in-depth system knowledge. If people are respectful of guidelines and communicate well, you can make any model work.
The number one requirement for any model is that your team can still meet the needs of the departments you're supporting. Good luck!
