The death of code has been prophesied for many years, and while this prediction is overhyped, it’s clear that the role of technical expertise in the enterprise is changing.
How can we tell? Shadow IT.
Shadow IT has been a conversation point for some time, but the general mental model of IT and technical expertise is still stuck in 1995. The fact that Shadow IT is so pervasive—numbers have estimated as much as 10x known app usage—is a sign that how technology is harnessed in the organization is out of step with how people think about technical expertise.
The dated mental models used today are based on organizations having two groups of people “IT” and “non-IT”. In this past, applications and information systems were primarily built and managed through code, complex configuration files, command-line tools, and SQL statements. With this level of technical expertise required, it created a clear delineation between the people who created, configured, and integrated the applications (IT) and the people who used the applications (non-IT).
Over the course of time, both the people and the technology have evolved. The technology has become increasingly more accessible through packaged cloud offerings, low-code/no-code solutions, and an increased focus on user experience. The people have also evolved as a new generation enters the workforce raised on iPads and Netflix and for the rest of us, apps and websites have become a regular part of everyday life.
Our perception of these skills in the organization is still rooted in the world of 20 years ago where there was truly a gap in technical skills between IT and business teams and where technology solutions needed deep technical expertise to deliver. At the same time, organizations have been struggling for years to improve IT and business alignment with limited success. Fundamentally, the lack of success can be attributed to this very same “us and them” mentality where it’s almost as if IT and the business are competing entities within the same organization. The technical experts vs the “non-technical” business.
This outdated perception leaves businesses with a false choice that is out of step with the rapid changes on the ground. The role of IT and CIOs in particular is changing in very visible ways. Low-code/no-code (LCNC) is leading to dramatic changes in how organizations interact with software. Discussions of big, tectonic shifts in how work gets done, like fusion teams or composable enterprises are well underway. It’s only with these shifts that we see organizations finally throwing away the old mental model and truly leveraging the technical expertise of the entire organization.
Related: Why citizen integrators are key to transforming your business
The service queue model is the first domino to fall
I recently worked with a customer who had their integration system handled by IT in a model where teams from around the business would log requests and wait in the queue to be prioritized. But despite the IT team having over 1,500 employees servicing a 20,000 employee organization, there were two people on the entire team that could deliver solutions using the integration middleware product. This created an obvious bottleneck.
This situation illustrates the state of many organizations. Technical expertise is misused because of our legacy mental model. Instead of realizing that a large portion of the same services can be delivered by less technical individuals, we remain stuck with the perception that technical services require deep technical experts.
But this is changing. The service queue model is giving way to more democratized approaches. Low-code is lowering the technical skill requirements and acting as the bridge between the business and technical worlds. With the bar lowered and the average technical skill of the organization increasing, the combination allows many more people to stitch together business systems, services, and experiences like building blocks.
In this scenario, technical expertise isn’t devalued, it’s simply refocused. Highly technical resources can now use their time more effectively by working on difficult problems/solutions that really make use of their technical expertise. They often move into an oversight and guidance role, enabling them to ensure that ALL solutions are delivered in a high-quality, safe, and compliant manner. Democratization is not about replacing technical expertise, it’s about understanding and using your organization’s technical skillsets effectively.
Related: How to set up an automation center of excellence
Democratization is not one size fits all
At Workato, we look at what companies are doing across the gamut. There is no one-size-fits-all structure, and although the role of tech expertise in companies is changing, that doesn’t mean every company needs to change right away. In our GEARS framework, we break it down into three different operating models—all of which have an Automation HQ team at the center:
- The centralized model: Teams focus on the service queue and have total control over what gets built. This is entrenched in traditional companies and can be difficult to change. It’s common with IT but can also be used in other departments, such as a centralized “marketing automation” team. While this works very well initially, it typically doesn’t scale, which leads organizations to employ the other approaches. Starting with a centralized model, however, is never a bad choice.
- The distributed model: Sometimes we also call this the federated model, and it’s where the building happens across the company (empowered by LCNC) while centralized standards and controls are still maintained by the Automation HQ team.
- The hybrid model: It’s a mix between centralized and distributed. Sometimes, this can be a transition point between centralized and distributed, and sometimes it just works better for companies.
Knowledge, control, & speed
Regardless of what model an organization employs, the role of technical expertise is changing along three levels: knowledge, control, and speed. Our mental models of technical expertise should shift to accommodate for these changes.
Knowledge: As the IT org shifts from following a request-service model into a guidance model, knowledge sharing grows in importance. There are different skill sets across teams, and leveraging them at the right time is key. IT and the business in particular bring different mindsets, and harnessing the strengths of each is the right approach.
Distributed teams can really struggle here if it isn’t done properly. As an example, the more technical team members might help ensure functions such as error handling, operational monitoring, security, and performance are properly considered, while the less technical (and often more business centric) individuals will ensure the solution is truly bringing business value by ensuring the requirements, workflows, and experience are optimal.
Control: IT teams are used to having total control in the service queue model, but shadow IT is a symptom of the drifting control that has gone on for years. Locking down only encourages more shadow IT. Rather, the right approach involves IT taking on the role of healthy governance in a measured way. When thinking about control, it’s crucial to shift the relationship to be less about command and control and more about enabling the team with the right standards and processes. IT needs to shift from being a barrier to being a guide.
Related: A guide to automation governance
Speed: This is the fundamental tradeoff with control—if IT relinquishes control, things can happen much faster. Reducing controls, and thereby increasing speed, can result in unintended consequences if taken too far. Therefore, it’s critical to ensure that oversight is maintained when thinking about democratization. Moving fast and maintaining controls is definitely possible, but it requires an intentional focus on both. Our GEARS framework is focused on doing exactly that.
Some of these statements may seem obvious. Others you may have heard before at a conference or similar. But watching organizations make the same mistakes over and over for the past decade suggests that something is amiss in how we are approaching technical expertise as an idea. If we begin to view it as something that’s distributed across the company rather than cloistered in a corner of the organization, we might realize that the overall approach to technology in the organization needs to change. That is when we see companies make big breakthroughs and start to achieve real transformation.
