9 tech leaders’ advice on running a technology organization (part 2)
A compilation of 8 tech leaders’ (+ BlueCat CSO Andrew Wertkin) advice on driving innovation and achieving overall success as a tech organization.
This article summarizes insights from Season 1 of the Network Disrupted podcast about how to run technology organizations to better serve business needs while controlling cost and complexity. Guests from large enterprises and vendors emphasize starting from business requirements, applying agile governance, documenting implicit knowledge, managing technical debt, and building baselines of capability to reduce fragility and enable flexibility such as multi-vendor cloud and SD-WAN strategies. Practical outcomes include improved alignment between tech and business, reduced operational risk from undocumented processes, and greater ability to adapt mid-flight without over-committing to expensive on-premises solutions.
Why do the guests argue that technology shouldn’t come first when solving business problems?
Multiple guests stress that technology-for-technology’s-sake leads to messy architectures and poor outcomes. Mat Chase explains that teams often present technology immediately, but the correct approach is to step back and clarify the business objectives because there are usually multiple technical ways to meet the same goals. Focusing on business requirements drives selection of solutions that deliver real outcomes rather than implementing tools that add cost, increase complexity, and create integration or operational debt.
How does documenting knowledge reduce system fragility according to the article?
Juha Holkkola highlights that much critical IPAM and operational knowledge lives in engineers’ heads, making systems fragile when teams change or when automation is introduced. By making implicit knowledge explicit—documenting baselines, processes, and configurations—organizations reduce single points of failure and enable reliable automation. This lowers the risk of breakage during upgrades or cloud transitions and helps teams adhere to standards and checks required in modern, software-defined environments.
What practical strategies do guests recommend for managing technical debt and maintaining flexibility?
Guests recommend treating technical debt as an integral part of delivery rather than an afterthought: Chad Sheridan warns that ignoring debt builds an ‘iceberg’ beneath the surface that will eventually impede delivery. Jon Macy suggests creating a baseline of functional capability so teams avoid constantly retooling expensive custom solutions. Anshuman Awasthi advises leveraging cloud and SD-WAN to avoid long on-prem commitments, use multiple vendors for traffic split and resilience, and favor API-integrated solutions to prevent vendor lock-in and preserve operational flexibility.
Technology teams are often at a handicap; they’re charged with meeting the business’ unpredictable needs at some level of predictable cost. At the same time, there are a hundred and one decisions to make, with exponentially more solution options, in pursuit of that goal. This complexity is a recurring theme on the show, with a lot of practical insights from guests.
The first part of this series focused on how our guests approach creating that critical alignment with the business.
Now it’s time to take a deeper dive into how they run their technology organizations.
A note before we begin: this series wouldn’t be possible without the openness of our exceptional show guests. If you see them around LinkedIn or Twitter, give them a virtual high five.
- David Markwell – SVP of Technology at Loblaw Companies Limited
- Mathew Chase – VP of IT at Ellucian
- Jon Macy – Director with Cerner Corporation
- Juha Holkkola – Founder and CEO of FusionLayer Inc.
- Anshuman Awasthi – Director of Infrastructure & Engineering with a leading furniture retailer
- Vishal Gupta – CTO at Unisys
- Thomas J. Sweet -VP in IT Solutions with GM Financial
- Chad Sheridan – Chief Innovation Officer with NetImpact Strategies Inc.
Find episodes on: Google Play | Spotify | Overcast
P.S. Network Disrupted is now setting sail for a second season, with new episodes dropping every Wednesday at NetworkDisrupted.com. Know somebody who should be featured? Send your recommendations to [email protected] or @netwkdisrupted on Twitter.
How to run a technology organization
Remember technology doesn’t come first; business requirements do
As Mat Chase notes in Episode 2 of the show, “it’s a really difficult solution. The first thing people come to the technology department with is technology.”
He says, “We keep smacking people back saying, ‘Time out. Let’s talk about really what are you trying to accomplish?’… There could be multiple solutions that are out there and we want to work towards good business outcomes and not just delivering technology solutions for technology’s sake.”
Later in the episode, he and host Andrew Wertkin get into the problem of how technology for technology’s sake creates a mess. Wertkin comments, “people often forget that technology selections are part of architectures and architectures don’t exist for any other reason than to meet requirements.”
Apply agile thinking all over
Chad Sheridan, Chief Innovation Officer at NetImpact Strategies, shares, “What I found was it doesn’t matter how well you perform in the development and operate a portion of that. If you don’t have a governance and picking model that is more akin with agile principles, you’ll never get off the ground or you’ll sub-optimize your process.”
Document knowledge to reduce system fragility
Juha Holkkola reminds us that a key way to keep processes healthy is to make implicit information explicit. “Some of the best IPAM tools I’ve seen are network engineers. They’re walking IPAM tools; they have everything in their head. But the problem is, if I’m going to automate something, it doesn’t work anymore.”
Think: baselines of functional capability
Given limited budget and capacity, Cerner Director Jon Macy shares his approach to prioritizing delivery of services. He says, “instead of flexing the technology all the time, which is horribly expensive at the end of the day (people, time, capital), what we want to do is create a baseline of functional capability and then see if the business can take their needs and requirements are and use that capability to its fullest.”
Get familiar with your processes
Some of the roadblocks to change will be ones you assume don’t exist. Juha Holkkola, CEO of FusionLayer, notes that most people don’t know “what is going on the networking side of things… It’s pretty deep down there. If you’re a C-level guy, it might be that you don’t really get that much visibility into the day-to-day activities of your networking teams. One good suggestion is to go there, speak with the guys, see what they are doing. Because what you’ll find is there’s loads of manual work and lots of things that haven’t really changed since the late ’90s.”
Then be accountable to your process
“You may have gotten away in the past and been lucky because you’ve had production drift or things that you could manage, but going to the cloud and going to a standard containerized architecture and everything being software-defined forces you to adhere to your own standards and to monitor and check them. Because guaranteed whether it’s the cyber criminals or whoever is out there, they’ll know when an endpoint comes unprotected a lot faster than you will because they’re checking them. So you better be checking equally well.”
Manage technical debt like someone will come to collect
In a similar vein, Chad Sheridan reminds listeners that, “your capacity to continue delivering those new capabilities is dependent on everything underneath the waterline on that iceberg. That is the technical debt, the legacy systems, all of those other things. And if you don’t integrally – if I can say that word – deliver that as you’re delivering features, then you’re just building more of the iceberg underneath the surface and eventually it’ll swallow you whole.”
Appreciate the fact that not everything can be measured
Some important things are hard to measure. Tom Sweet, VP in IT Solutions at GM Financial, reminds listeners of this time-tested wisdom. “[Martin Fowler] had a blog post about measuring programmer productivity. And he says it’s really hard to measure programmer productivity. You can’t look at lines of code. You can’t just look at defects. So if you could read his post, it’s not that long, but he makes a lot of sense and so when people say, “How do you measure individuals?” It’s hard, right?” The thought applies to more than just programmer productivity, but a lot of areas in the business as well.
Carve room for flexibility
The plan tends to change mid-flight. Director of Infrastructure and Engineering at a leading retailer, Anshuman Awasthi, says, “I think the beauty of the cloud is, you can have two technologies. There is no big commitment that you have to make like three years, four years, when you have bought something on premises. You are making a commitment for three, four years for on-prem, not for the cloud.”
Referring to the flexibility that affords, he adds, “You can have two different vendors. With one, you can have 30% of the traffic, the other one maybe doing 70%. Based on the confidence that you have, and with SD-WAN you can maneuver it. What is coming up slowly is the API integration, where I’m not dependent on a vendor, for the technology that I want to choose.”
See the truth in the middle
Many very practical technologies today are surrounded with both hype and cynicism. The truth is somewhere in the middle, as Unisys CTO Vishal Gupta reminds us in reference to Artificial Intelligence. “I think the balance comes in. You can either hype AI not to be so afraid of it that you don’t leverage it. That’s where the balanced approach is needed.”