Modern Engineering Practices Applied to Enterprise IT

8 min readJun 2, 2022

Can the world of traditional IT be transformed into a high-performing, high-impact function by adopting modern DevOps engineering practices? The answer is, of course, YES. This blog is the story about how I was able to test this hypothesis when I pivoted from Engineering to Enterprise IT in mid-2021.

The Opportunity

I spent the first 20 years of my career in Software Engineering, and I loved every minute of it: writing and deploying code, solving complex problems with simple solutions, nonstop learning and innovation. I progressed from Developer to Architect, from Management to Senior Leadership. A CTO position was my north star career goal, though I more often heard from recruiters filling CIO roles because I had “Business Systems” in my title. But the world of IT just didn’t interest me. Helping people with their laptops, administering email, managing firewalls and VPNs, software rationalization, vendor relationships. It sounded a bit boring to me.

Then in August of 2021, I was given an opportunity to lead Enterprise IT, but unlike other CIO roles I had been offered in the past, this appealed to me for 2 reasons:

Comfort (I knew what I was getting into). The opportunity was for the company I was already working at. People with technical skills can pretty much choose to work anywhere we want, but I had chosen to stay at that company for over 9 years because we had a noble mission, a great culture and strong leadership.
Growth (It wasn’t going to be easy). There was consensus that our IT Department was no longer meeting the needs of our business, but little agreement on what was needed to turn it around. Over the previous few years, our IT Department had reported up to 5 different executives: CTO, COO, CFO, Chief of Staff and finally our Chief Administration Officer who recognized the need to bring in strong technical leadership to oversee this function.

I love a good challenge, so I gladly accepted the role to lead Enterprise IT, a global team of about 90 people, which included Corporate IT, Data & Analytics, Business Applications and PMO. I had a strong intuition about how to turn this department around, but the first rule of digital transformations is that every situation is unique, meaning the same playbook cannot be applied to every situation. So, the very first thing I did was give myself 30 days to go on a 360-degree listening tour and see what I could learn.

Results of the 30-Day Assessment

IT was underperforming. It wasn’t just a perception that IT wasn’t meeting the needs of the business. We were in constant firefighting mode, dealing with emergencies, escalations, and constantly changing priorities. The applications we supported were unstable. We would deploy changes to one area of an application, only to have something else in another area break. Changes often had to be rolled back. Legacy point-to-point integrations between applications were also unstable, but instead of fixing the code, people would just manually push data through to keep business operations running.
Low Trust. When I met with the heads of the departments we work closely with — Marketing, Sales, Finance, Delivery and Support — they all said some variation of the same thing: “IT doesn’t understand the business, they don’t know what they are doing”. But when I met with IT, they all said the same thing as well, “The business doesn’t understand technology, they don’t know what they are doing.” The business was pointing at IT for the failures of the past, and IT was blaming the business.
Deadlock & Learned Helplessness. We had done a major acquisition the year before and had integrated people and teams to operate as one company, but we still had separate systems: 2 Salesforce instances, 2 Netsuites, 2 Marketos, etc., so it still felt like we were running two separate companies. Consolidating systems into single instances was the number one priority for IT over the past year but no real progress had been made. We couldn’t reach consensus on an approach or plan, so nothing was getting done. We were deadlocked, and the longer we went with inaction the more frustrated people got with IT.
People were defeated. The worst part about all of this was the impact on people. Employees who used to feel confident and empowered were now working harder and harder but accomplishing less. They felt defeated, unvalued, and burnt out.

A leaking boat with 2 people at one end using buckets to pour water out, and in the other end are 2 people saying “I’m sure glad the hole isn’t in our end” — IT & the business were on different ends of a sinking boat.

Deja Vu

The reason this sounded particularly interesting to me is because it was all too familiar. Over the previous few years, we had done a major modernization of our product engineering org, going from monolith to microservices, on prem to cloud, quarterly big bang releases to continuous delivery. The situation in IT sounded very similar to our engineering org before our transformation and I wondered: could modern engineering practices be applied to enterprise IT to get the same results?

Time to “DevOps the Hell out of IT”

I had a strong feeling IT could benefit from modern engineering practices, so I set out to test that hypothesis, or as I like to say, I was going to “devops the hell out of IT”. My transformation plan involved 3 areas: culture, technology, and flow. Here’s how I approached each area over the past 8 months.

Part 1: Culture

The most important aspect of any digital transformation or technology modernization initiative is establishing the right culture, and it was clear we didn’t have it. We couldn’t start doing any actual technology work because the current dynamic was too dysfunctional. Egos were big — everyone thought they alone had the correct solution and wouldn’t listen to other people's ideas. It was all talk and no work. The culture had to be fixed before we could expect any real progress.
Established one team mindset between IT & the business and rewarded outcomes over output. It wasn’t enough to have aligned goals, we took it a step further to have the same goals. There would be no more “I did my best, but the other department didn’t do their job”. It was now “We all succeed, or we all fail.”
Focused on psychological safety, continuous improvement, collaboration, customer focus, transparency and sharing, largely modeled after the Westrum generative culture which promotes innovation.
Let leader's lead. Everyone was coming directly to me to solve every problem. I empowered leaders under me and worked to push authority and decisions down the org as far as possible.
And lastly, we needed to change from trusting people over systems to trusting systems over people. This shift to a technology mindset was the hardest part because our systems did have quality issues, so I understood why no one trusted them, but I also knew if we were going to turn the department around, we needed to leverage technology and not solve our problems with people.

Part 2: Technology

Our systems had grown organically over our company’s 20 years, which means years of unpaid technical debt and massive complexity due to features being built on top of features without a strong technical architecture or foundation. Applications should be easy to use, disappear into the background, and ideally should help accelerate the business. But in our world, our systems were actually slowing down the business. It’s pretty bad when Sales starts to blame internal systems for not winning deals.
Automation creates compound effects, but we had far too much manual work. I invested in building out a DevOps function and gave them a simple mandate: automate everything. Automated regression testing and deployments was first on the list. We moved from weekly releases to automated on-demand deployments.
Data needed to be foundational to everything we do and not a bolt-on. We had an emerging data team, but the perception was we weren’t getting value from them and some folks in the business thought we should shut it down. On the contrary, I increased our investment, doubled the size of the data team, and started using the Data Lake not just as a repository for reporting but as a Data Hub so we could decouple systems and make them easier to migrate.

Part 3: Flow

Even with a generative culture and a robust IT systems environment, no technology team can be successful without solving for flow. Because the business world is constantly changing, technology needs to be incredibly agile and provide value continuously.
Make Work Visible was our rallying cry to improve flow. Previously, teams would get work through multiple channels –JIRA tickets, Service Now tickets, as well as emails and slack. We’ve since migrated to a single system to manage all work which means it’s easier to prioritize and see exactly what needs to be done.
Generally moved away from big bang project releases towards MVPs and continuous delivery with shorter feedback loops.

Did it work?

YES. And here’s how I know:

People tell me it’s working. Not exactly a quantitative measure, but when all I heard 9 months ago was that IT needed to be improved, that wasn’t exactly quantitative either. When the Executive Leadership team told me IT has improved and we’re in a much better place, it means trust had been re-established. It may not mean we had achieved high performing status, but no one can build high performing teams without a foundation of trust.
Successful Releases. Since shifting to more frequent deployments, smaller releases, and investing in test automation, there has not been a single release we’ve had to roll back post deployment. Failure rate has dropped significantly.
Fly Wheel Spinning. Adopting small releases and feedback loops means we’re no longer spending time in meetings whiteboarding and planning what huge features to build, only to continue with endless debate and stay deadlocked. We’re now empowered to build small experiments and build incrementally.
Data Driven. Because all work is now being tracked in a single system, we have data to measure what is being deployed week over week and can have more fact-based conversations about IT performance.
Increased stability. We’re no longer in constant firefighting mode. Most of the frequent errors that required manual intervention are now being handled by code & automation.

Of all the benefits we got by applying modern engineering practices to IT, the most important one, the one I am most proud of, is the impact to people. People are happier. They are no longer battling with colleagues, they aren’t wasting time proving their value, they don’t feel insecure or helpless. Employees are coming to work with clarity on what to work on, how to get work done, and they know why their work is important. And that is something we can all feel good about.