Fred Coia

Fred Coia is the Chief Strategy Officer with Shaw Systems Associates. He has occupied numerous technology leadership positions in which he has led the transformation of the business.

As a CIO or chief technology officer, it can feel like your peers are always getting farther and farther ahead of you as they adopt exciting-sounding methodologies like Bi-Modal, Agile, Scrum and Dev Ops. So, what can you do as a technology leader? First, you can take a deep breath. You are not alone and you don’t need to get confused by all of the marketing buzzwords.

Yes, these new concepts and terms are different, but only slightly different from what I call like to call “IT 101.”

If you’re still feeling overwhelmed, consider this comparison to the NFL. Every year there are new offensive and defensive schemes. On the offensive side, there’s the “West Coast,” “Run and Shoot” and “RPO” or “run, pass option.” On the defensive side, “4-3,” “3-4,” “Nickel,” “Dime,” “Cover 2,” and my personal favorite, Buddy Ryan’s “46”.

While these schemes sound new and exciting, they were all developed using the same fundamental ideas and actions: blocking, running, passing and catching on offense; tackling and staying in one’s gap on defense. As a technology professional, you already know how to block and tackle. That’s the “IT 101”. You simply need to learn the new schemes and techniques.

Knowing your product inventory

As a first step to adapting these new approaches, you need an application inventory or catalog. This enables you to see what you are responsible for and how the apps support your business. Each catalog entry should track the following:

1. Name
2. Business or product owner
3. Technology lead or owner
4. Primary business unit that app supports

Only when you have this information can you evaluate whether the business unit and product owner are aligned. Ask yourself: Does the product owner report directly to the person in charge of the business unit that’s using the app? Does the product owner have enough time to provide the product team with direction and address questions in near real-time? And so on.

Evaluating product friendliness

Legacy applications were not built into this model, so in most cases, they, along with retraining of staff are going to be the biggest obstacles to achieving digitalization. Likely, your staff will repeatedly state that new apps cannot work in this new DevOps model. In most cases, they will truly believe this and will probably be able to produce valid arguments in their defense.

There are essentially two or three options. You can replace these legacy systems, keep them or evolve them. If a near term business case cannot be made to replace them, then I always look at ways to evolve the application that limits the impact of the technical debt.

This may involve using a web service to enable real-time updates on a legacy batch mainframe application. Or, it could entail consolidating functionality that is deployed in multiple places so that it takes less effort to maintain. The amount of effort on updates depends on the importance of the legacy system to the business.

Organizing staff accordingly

Now, it’s not just the systems that need to change. It’s time for you to expand your horizons, as well.

For instance, most of us entered the job market at a time when people were separated and segregated by their skills. Likewise, we reported to people with the same or similar skillsets in what’s called a “solid line” approach.

Today, however, it is increasingly necessary for people to be grouped based on what an application or product requires. That means if developing a product requires the input of a Java programmer, an ETL developer and a quality assurance analyst, they should all work together under the same manager with the same goals.

All the while, it is important to implement a new “dotted line” reporting relationship so that all similarly skilled staff can continue to meet regularly to share and commiserate on best practices.

Likewise, IT Management has to change, and your VP of development needs to shed her or his prized “development” title and assume the title of “VP of sales systems” or “director of servicing systems” and manage all technology disciplines that may even include a systems admin.

Educating and partnering with your business colleagues

When discussing this reorganization internally, it is important to frame it as a business problem with IT playing a major role in solving it. Investment from the business side must include business engagement in addition to funding.

Most important is the allocation of subject matter experts and product owners. In some cases, this may be the same resource. In others, the product owner is the quarterback, and the subject matter experts are the wide receivers, running backs and linemen. The main thing to get across is that the resources are a team and thus need to work together.

Just as important is properly informing the business that there is more to applications than business functionality. They need to understand the risks of “technical debt” and the impact of ignoring it over time. As an IT leader, you must explain these risks in business terms and not simply take the route of scaring them with statements like, “If we do not implement a performance environment, then our systems will more than likely crash during peak season.”

You must be prudent in your requests and not ask for too much in terms of resources. Think out of the box and be creative; you may decide to validate your analysis in phases, if necessary.

Are you still feeling overwhelmed? It’s okay. The thing to remember is that you are not alone; we have all encountered these career challenges. Focus on your business goals and align your technology staff accordingly. Alignment and collaboration are essential!