top of page

Service Requests Mentality is a Blocker to Digital

IT must become a partner and enabler of digital — not a service provider

By Bradley Clerkin, BreakFree Solutions CTO

Becoming digitally capable requires a different form of engagement than the form IT groups have mastered, which involves consistently engaging through service request mechanisms and ticketing systems.

Today's successful CIOs help their IT leaders understand that users don't want to come to their portals to request standard services.

In the digital landscape, IT focuses on partnering on a journey. This statement may sound like fluff but stay with me; I assure you it's not.

Embracing the Partnership Mindset

In a partnership mindset, IT organizes around the ability to adapt based on their customer's constantly changing needs and demands.

They embrace the idea that the future of the digital product is unclear—we don't know what it will look like in six months. Rather than wasting time to mis-predict the future, IT leaders need to make the journey.

Leaders with this mindset coach and employ teams and individuals who avoid red-tape standard processes and instead take a pragmatic approach to process.

Examples of a Partnering Mindset in Action

1. IT Operations supplies programmatic interfaces that enable digital groups to send change, asset, configuration, and compliance data. IT operations then help them pass back-end audits and verification activities with the data.

In a traditional services-based approach (the old way), we'd try to force everyone into a specific approach and lane and then ensure that the lane has consistent verified operational guardrails. In the new digital landscape, we assume we have no idea what the team will build, so we enable teams to send us information and add value by helping them pass audits with the data they send.

2. IT builds guardrails that enable development teams to use and configure cloud systems in whatever platform they need to create. When developers bump into guardrails, engineers engage with developers to see if there is an opportunity to improve their guardrails through a partnership.

In a traditional services-based approach, teams build cloud systems in a standard way with a stringent process for variability to configuration. The team perceives developers as not having the skills or ability to use cloud safely.

3. IT architects create communities of practice that share common practices that engineering teams have gravitated toward.

In a traditional services-based approach, architects limit the variability of practices and solutions to decide how the team will do things. Now, architects enable these decisions to be made on development engineering teams and focus on being a catalyst for sharing between teams.

Questions to Ask Yourself

The ability for IT to shift to being a partner and enabler of digital from a service provider to the business is the foundational litmus test for IT leaders who want to make their IT group digitally capable. We think leaders should ground themselves with some basic questions:

  • Are we controlling or enabling?

  • Are we centralizing or decentralizing decision-making?

  • Are we embracing variability?

  • Are we more focused on getting movement than knowing exactly where we will end up?

  • Are we putting buffers between groups where we should be partnering?

To keep up with the ever-changing digital landscape, IT groups must shift their engagement strategy. This means moving away from a model of consistently engaging through service request mechanisms and ticketing systems, and instead embracing a partnership mindset in which they can adapt based on their customer's constantly changing needs and demands.

If you're looking for help making this transition, reach out to BreakFree. We can help you get your IT group on track for success in the digital age.

Recent Posts

See All

To Adopt DevOps, You Need a Game Plan

Through the DevOps Playbook Framework, enablement teams now exactly how to support the adoption of this core capability By Bradley Clerkin, CTO We often meet IT leaders and their teams in this situati


bottom of page