Business → IT | IT → Business

Every IT project starts with the same familiar debate: should we buy a package or build it ourselves? The problem is that this question is a trap. Buying still means you own integration, customization, upgrades, and the business process changes that come with it. Building means you own the code, the talent, the technical debt, and the long-term roadmap. This episode shows why the real decision is about ownership—of functionality, data, risk, and organizational capability. Mirko Peters explains why 'buy' rarely means 'done,' why 'build' rarely means 'unique,' and how to reframe the conversation around total cost of ownership and strategic control. He shares a generalized consulting example of a company that bought an off-the-shelf CRM, then spent eighteen months customizing it until it was neither standard nor simple. The result: the worst of both worlds. Practical takeaways help business leaders and IT teams ask better questions before committing millions. If you are facing a buy/build decision, this episode will change how you think about it.

Become a supporter of this podcast: https://www.spreaker.com/podcast/business-it-it-business--6867401/support.

To continue the conversation, follow Mirko Peters on LinkedIn, where more insights and real-world examples are shared from both business and IT perspectives.

Estimates are the quiet battleground of business-IT alignment. Business hears a number and turns it into a budget, a roadmap, a promise to the board. IT knows the number is a guess wrapped in assumptions about scope, dependencies, and unknowns. Then the guess hardens into a deadline, and everyone starts protecting themselves: buffers get hidden, scope gets squeezed, status reports soften reality. This episode explores why an estimate is not a commitment and why treating it as one is one of the most expensive mistakes organizations make. Mirko Peters breaks down how business and IT use the same word to mean different things, why single-point estimates are so dangerous, and how to separate the conversation about uncertainty from the conversation about commitment. He shares a generalized consulting example where one number derailed a program, and gives practical takeaways that help business leaders ask better questions and IT teams give more honest answers. The goal is not better estimates—it is better decisions under uncertainty.

Become a supporter of this podcast: https://www.spreaker.com/podcast/business-it-it-business--6867401/support.

To continue the conversation, follow Mirko Peters on LinkedIn, where more insights and real-world examples are shared from both business and IT perspectives.

Every IT project starts with a budget decision, but most business leaders treat the budget as a purely financial constraint—while IT teams treat it as a mystery that prevents them from building the right thing. The result is an architecture that nobody designed: siloed systems, duplicated capabilities, and technical debt that quietly grows with every funding cycle. This episode argues that the budget is not just money; it is the most powerful architecture decision an organization makes. When a business unit funds its own tool, it creates a silo. When finance insists on short-term cost savings, it defers the platform investment. When capital and expense rules change, they rewrite the system landscape. Mirko Peters explains how to see the technical consequences of every funding model, why finance and IT speak different languages, and how to align budget allocation with the target architecture. You will learn how to spot the budget decisions that shape your systems and how to turn funding from a constraint into a strategic lever.

Become a supporter of this podcast: https://www.spreaker.com/podcast/business-it-it-business--6867401/support.

To continue the conversation, follow Mirko Peters on LinkedIn, where more insights and real-world examples are shared from both business and IT perspectives.

Every pilot project starts with cautious optimism and ends with a decision: do we scale this or not? Too often, business and IT answer that question differently. Business sees a successful pilot as proof that the idea works. IT sees a pilot as a controlled experiment that was hand-built, closely watched, and excused from the usual constraints. This episode looks at the pilot paradox: why a small win can become the most dangerous deliverable in a transformation program. We explore what business really means by 'it works,' what IT means by 'it's ready,' and why the gap between those two statements is where projects stall. You'll hear a generalized consulting example of a regional pilot that looked great and failed at national scale, plus practical questions to ask before you start any pilot. If you want to stop confusing proof of concept with proof of value, this episode gives you a clearer way to think about pilots, rollouts, and readiness.

Become a supporter of this podcast: https://www.spreaker.com/podcast/business-it-it-business--6867401/support.

To continue the conversation, follow Mirko Peters on LinkedIn, where more insights and real-world examples are shared from both business and IT perspectives.

Every organization has a data quality problem. Business leaders see incorrect records, duplicate customers, and missing fields—and assume IT can fix it. IT teams know the data isn't the root cause; it's the output of broken workflows, missing ownership, and incentives that reward speed over accuracy. This episode flips the conversation. Mirko Peters explains why data quality is a business process problem wearing an IT costume, why cleaning data without changing the process is like mopping the floor while the tap keeps running, and how to stop the cycle. You'll learn how to define data ownership, how to turn data quality into a process requirement instead of a fire drill, and why the real fix often has nothing to do with technology. Practical, direct, and grounded in real consulting experience.

Become a supporter of this podcast: https://www.spreaker.com/podcast/business-it-it-business--6867401/support.

To continue the conversation, follow Mirko Peters on LinkedIn, where more insights and real-world examples are shared from both business and IT perspectives.

IT's 'no' is rarely a refusal. It's a hidden yes—to keeping systems stable, to protecting security, to maintaining commitments already made. But when that logic stays invisible, business hears only rejection. This episode unpacks the unspoken trade-offs behind IT constraints and shows why every 'no' is actually a prioritization signal. Mirko Peters explains how to make these implicit choices explicit, using a simple framework to surface what IT is saying yes to instead. You'll learn how to reframe 'no' as an offer to negotiate trade-offs, why vague requests often create the very refusals they complain about, and how to turn conflict into a clear decision process. If you've ever been frustrated by an IT shutdown or had to defend an infrastructure decision, this episode gives you a new language for moving from opposition to alignment.

Become a supporter of this podcast: https://www.spreaker.com/podcast/business-it-it-business--6867401/support.

To continue the conversation, follow Mirko Peters on LinkedIn, where more insights and real-world examples are shared from both business and IT perspectives.

When business leaders say 'we need to integrate these systems,' they usually mean 'make the data flow so we can see one truth.' IT teams hear a technical project: APIs, mappings, error queues. But the hardest part of integration is rarely technical. It is organizational. Every system boundary reflects a boundary between teams, budgets, and decisions. If two departments can't agree on who owns a customer record or what 'active' means, no interface can save the project. In this episode, Mirko Peters shows why integration projects fail before a single API is built, how to spot the real owners and hidden assumptions, and how to turn an integration request into a conversation about governance and trust. You'll learn practical ways to expose the organizational questions hiding inside technical requests—and how to prevent the expensive, frustrating cycle of connected systems that still don't produce aligned decisions. This is a clear-eyed, practical look at why system integration is business integration.

Become a supporter of this podcast: https://www.spreaker.com/podcast/business-it-it-business--6867401/support.

To continue the conversation, follow Mirko Peters on LinkedIn, where more insights and real-world examples are shared from both business and IT perspectives.

Every requirement is a promise until it's a test. In this episode, we explore why automated tests are the only precise, unambiguous specification of what a system should do, and why they're often the last thing business stakeholders see. We'll look at the business perspective: why documents feel solid but are actually fuzzy. We'll look at the IT perspective: why developers trust tests over conversations. And we'll expose the gap that leads to costly rework. With a real-world example of a claims system where a single test revealed a missing definition, you'll learn practical ways to turn tests into a shared language. If you're tired of misunderstandings between business and IT, this episode gives you a clear, actionable path to alignment. No jargon, just honest advice from both sides.

Become a supporter of this podcast: https://www.spreaker.com/podcast/business-it-it-business--6867401/support.

To continue the conversation, follow Mirko Peters on LinkedIn, where more insights and real-world examples are shared from both business and IT perspectives.

{"title":"The Legacy System Is a Business Decision: Why Old IT Isn't a Technical Problem","one_liner":"Legacy systems aren't just technical debt—they're a series of business choices frozen in code, and pretending otherwise leads to expensive rewrites and missed opportunities.","description":"Every organization has them: systems that have outlived their welcome, yet somehow remain mission-critical. We blame bad architecture or outdated technology, but the real reason legacy systems persist is simpler and more uncomfortable—they are the frozen residue of business decisions made years ago. In this episode, Mirko Peters unpacks why legacy isn't a technical problem, but a business one. He explains how risk aversion, sunk costs, and political dynamics keep old IT alive, and why modernization projects fail when they ignore the business logic embedded in the code. You'll learn how to reframe legacy as a portfolio of choices, how to identify which parts truly need replacing, and how to build a business case that speaks to both finance and engineering. If you're tired of rewrites that don't deliver value, this episode gives you a practical framework for making legacy a strategic advantage instead of a liability.","why_now":"Legacy systems exist in every industry, at every company size, regardless of technology trends. The conversation about modernization is perpetual, but the underlying dynamics—business risk, sunk cost, organizational inertia—remain constant. This episode addresses a timeless challenge that never goes out of style.","target_audience":"Leaders, consultants, and IT professionals who struggle with modernization decisions and want to understand the business forces that keep old systems alive.","episode_type":"monologue","estimated_runtime_s":1320,"outline":["00:00-01:30 — Opening & Context: Introduce the paradox of legacy systems—everyone hates them, but they persist. Set up the central thesis: legacy is a business decision, not a technical failure.","01:30-06:00 — The Business View: How business leaders perceive legacy systems as 'safe' and 'working.' Discuss risk aversion, sunk cost fallacy, and the fear of disrupting revenue streams. Explore why executives often prefer incremental patches over bold modernization.","06:00-10:30 — The IT View: From the IT side, legacy systems are seen as fragile, undocumented, and hard to maintain. Explain the technical constraints—aging skills, integration spaghetti, and the cost of re-platforming. Highlight why engineers often push for rewrites while business pushes back.","10:30-14:30 — The Gap in Between: Where the disconnect happens. Business says 'don't break what works,' IT says 'this is unsustainable.' Unpack how different time horizons, risk tolerances, and vocabularies create a communication chasm. Show how this gap leads to stalled projects and mutual frustration.","14:30-18:00 — Real-World Perspective: Share a generalized consulting example—a company that tried to modernize a legacy order management system and failed because they ignored the embedded business rules. Then discuss a second attempt that succeeded by treating the legacy system as a set of business decisions, not just code. Draw out the key lesson: understand the 'why' behind the legacy before touching the 'how.'","18:00-21:00 — Practical Takeaways: Give concrete actions for both sides. For business: ask 'what decision does this system encode?' and 'what would we do if we could start fresh?' For IT: stop proposing full rewrites; propose small, high-value replacements. Emphasize building a business case that quantifies the cost of doing nothing.","21:00-22:00 — Closing & Call-to-Action: Recap the core idea—legacy is a portfolio of past decisions, and modernization is a strategic re-evaluation, not a technical cleanup. Encourage listeners to subscribe, leave a review, and connect with Mirko Peters on LinkedIn for more insights.","tags":["legacy systems","technical debt","business strategy","modernization","change management"],"duplication_check":{"nearest_match_title":"The Business Rule That Outlived Its Reason: How Old Decisions Become New Constraints","similarity_score":0.2,"decision":"distinct"},"risks":["Oversimplifying the technical complexity of legacy systems","Potentially sounding like a justification for leaving old systems alone","Ignoring cases where legacy truly is a technical dead end and needs urgent replacement"],"mitigations":["Acknowledge that some legacy systems are genuinely past saving and need replacement for technical reasons","Emphasize that the point is not to preserve legacy, but to understand it before deciding its fate","Balance the business perspective with concrete technical examples and caveats about security and performance risks"]}

Become a supporter of this podcast: https://www.spreaker.com/podcast/business-it-it-business--6867401/support.

To continue the conversation, follow Mirko Peters on LinkedIn, where more insights and real-world examples are shared from both business and IT perspectives.

In this episode, Mirko Peters takes on shadow IT—the unofficial spreadsheets, cloud apps, and small scripts that business teams adopt to get things done when IT seems too slow. He explores why shadow IT exists, the real costs it hides (integration headaches, data silos, security risks, duplicated effort), and why the typical IT response—banning it—makes things worse. He offers a practical framework for turning shadow IT into a source of innovation and visibility, aligning business agility with enterprise governance. Listeners learn how to distinguish benign workarounds from critical systems, how to create a 'bring your own tool' policy that works, and how to migrate shadow systems into the architecture without breaking the momentum. The episode is packed with real-world examples, including a marketing team's spreadsheet that became mission-critical and almost caused a disaster. It's a must-listen for business leaders who want speed without chaos, and IT professionals who want control without killing innovation.

Become a supporter of this podcast: https://www.spreaker.com/podcast/business-it-it-business--6867401/support.

To continue the conversation, follow Mirko Peters on LinkedIn, where more insights and real-world examples are shared from both business and IT perspectives.