It wouldn’t be a blog about Information Technology without posting this clip from “The IT Crowd,” but those of us actually in the IT business know that this hasn’t been the role of IT teams in modern companies for years now. It’s still funny, though!
The fact that IT has become a lot more than tech support is old news, but you might not realize how much and how quickly the role is still changing.
Gainsight was a fast-growing company when I got hired on as the CIO—and it’s growing even faster now! But when I started, there had been no central applications management function—each department was taking care of their own needs for several years and had at least one person doing applications maintenance (sometimes full-time). While this addressed the immediate needs of each group, we were starting to see problems arise due to uncoordinated activities across applications.
This is nothing new in the IT world. Even larger, highly established companies face these challenges in the new world of SaaS, especially those undergoing a digital transformation. Today, any employee, team or department can spin up their own applications. As a result, a major part of IT’s responsibilities today is to coordinate better collaboration across departmental silos.
These silos have differing or competing goals and strategies. As a result, most companies (even small start-ups) deal with some combination of miscommunication, redundant or overlapping systems, and inconsistent or incomprehensible data. To solve these challenges, many orgnaizations would take the traditional approach—move everyone working on applications into IT and (try to) centrally control all applications. I believe in the era of digital transformation, IT leaders need to take a more distributed approach.
IT as a Facilitator, not a Dictator
That “traditional approach” I mentioned is a sort of top-down method that might work okay at your company and probably seems like the only sensible solution to the fragmentation challenges that arise with the sheer weight of different applications and systems your company is using. You do an inventory of all the tools people are using, keep (or acquire) the most effective ones, cut the most expensive and redundant ones, make as few exceptions as you can, and build the “right” tech stack.
That all still needs to happen, but in the new world I see the effort as being more collaborative than in the past. IT is more important than ever in helping drive a coherent architecture that integrates and enables all those departmental applications to meet both their departmental needs and the broader business imperatives (e.g. supporting cross functional business processes, managing applications spend, and alignment with strategic goals). However the days when IT simply laid down the law are passing quickly and I believe we need a mindset that embraces collaboration rather than control.
As we grow our IT Applications team we will be able to take more and more of the application management burden off our departments, but I think there will always be people doing application work scattered throughout the company. And rather than see that as a bad thing (what we used to call “Shadow IT”), I’m embracing it and experimenting with different models for governance and collaboration.
Here are three axioms of this “facilitator” model I put in place:
1. Get the right people in the room
I started by creating an Applications Coordination Team (ACT). Every three weeks, nearly a dozen representatives from various functional groups, such as Engineering, Sales, and Customer Outcomes meet up to address our various systems and apps and the needs and challenges of their respective teams. I don’t only want to talk to the most senior strategy-makers—I want to talk to admins and end-users too.
None of this works without the right people and I’ve been lucky to work with a team that has a great attitude—if people were holding back, not sharing what’s going on in their space, this would all collapse in a hurry. However, I think this approach could be successful in a more challenging environment, as long as there’s a critical mass of folks with the right attitude. At some point, you create enough peer pressure that even those dragging their feet get pulled along.
2) Specificity is key
I’m all for thinking about high-level strategy, but when it comes to the actual decision-making job of a CIO, the devil’s in the details. I decided on an every three weeks schedule; bi-weekly tends to be too operational, monthly too infrequent to sustain momentum. I wanted clear guidelines about what we cover in this team.
Here’s a general example of the meeting agenda:
- Change Management
- Review upcoming planned changes
- Ensure up/downstream impact is understood
- Environment Management
- Coordinate sandbox refreshes
- Project Updates
- Provide visibility to in-flight or planned projects with cross-functional impact
- Process Improvement
- Ways to improve how we work together
- How requests are made, prioritized, and managed
- Admin access policy
- Shared tools (e.g. ticketing system)
- Strategic Planning
- Long-term project roadmap
- Master Data Management
- Application architecture
- Special Projects (e.g. M&A)
Each meeting we have roundtable discussions where each team sharesd project updates, upcoming changes, and any other relevant information. In addition, we often focus on a specific, strategic topic, such as how to leverage common tools or what our long-term plans are.
A great example was our recent acquisition of Aptrinsic. As most fast-growth companies know, acquisitions create a lot of work for IT. In this case, the ACT was the perfect group to make sure we had a cross-functional approach to our integration. IT managed the overall program and ensured dependencies were addressed, while others worked on their own applications. We have also spun out smaller sub-teams for specific topics, like addressing the Quote-to-Cash aspects of our Aptrinsic integration and rationalizing our Knowledge Management tools.
3) Qualify the impact
Obviously when it comes to business, ROI is everything. And that’s important to quantify according to your objectives and key results. But what about what the data doesn’t show? It’s equally important to understand the qualified effects of your facilitator strategy. Since we implemented it here at Gainsight, there are a few ways we’ve seen our ACT impact the company.
- Increased proactivity: The highly engaged team creates solutions before a problem arises, and potential issues are avoided because we were better able to share information.
- Better communications across department silos: While the ACT isn’t in one specific department, it feels like a team. It also feels good to feel less alone; sometimes just commiserating with others who are facing the same challenges (demanding users, frustrating vendor support, etc.) can help. Since we’re all in the same boat, we should have each others’ backs.
- A foundational structure for special projects: When the M&A process came along, we were ready for it with an already formed team. I have a feeling other projects will come along that will make us all happy we have this structure solidly in place.
As companies grow and update their tech stack, the Applications Coordination Team will likely evolve with it. Throughout all the change, the one thing that shouldn’t change is the spirit of being facilitators first.
What do you think? I’d love to hear from IT leaders, application admins, and other people managing systems and software in the age of digital transformation. Do you have a framework similar to ours? Or maybe something better! Please feel free to email me at karl_mosgofian@gainsight.com.
