Business → IT | IT → Business

Organizations often ask IT to automate a workflow because the process has already been documented, approved, or drawn in a familiar diagram. That apparent clarity can be misleading. A workflow describes the sequence people follow; it does not necessarily explain the customer outcome, decision logic, hidden manual effort, or constraint the sequence was meant to address. This episode examines how business teams mistake visible activity for meaningful work, and how IT can accidentally turn an inefficient process into a faster, more rigid system. Mirko Peters looks at the assumptions on both sides: business wants consistency and speed, while IT needs precise rules, ownership, data, and exceptions. Through a generalized consulting example, the episode shows how to test a process before automating it. Listeners will learn practical questions for separating purpose from procedure, identifying unnecessary steps, and deciding when simplification should come before implementation.

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.

Organizations often treat approval as the end of a conversation. A business sponsor signs a requirement, a steering group endorses a design, or a process owner approves a change, and everyone moves forward assuming the important choices are settled. But approval can mean many different things: agreement with the goal, acceptance of the risk, acknowledgment of the wording, or simple permission to continue. When those meanings are confused, IT builds against apparent certainty while business leaders believe they have preserved flexibility. This episode examines the difference between reviewing, agreeing, deciding, and accepting consequences. Mirko Peters uses a generalized consulting example to show how a project can have abundant signatures yet lack a real decision on scope, trade-offs, ownership, or success criteria. Listeners will learn how to make approvals explicit, expose unresolved choices, and reduce rework without adding unnecessary bureaucracy. The episode closes with practical questions both business and IT can use before calling something approved.

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.

A business request rarely reaches implementation in its original form. It passes through meetings, documents, tickets, models, estimates, and approvals, with each handoff simplifying the message. By the time IT delivers what was written, the organization may have lost why the request mattered, which assumptions shaped it, and what outcome was actually expected. This episode examines handoffs as a form of lossy compression: useful information is removed, ambiguity is normalized, and nobody notices until the result fails in production or frustrates users. Mirko Peters looks at the issue from both sides. Business leaders will hear why repeating a request is not the same as transferring intent. IT professionals will hear how technical precision can still preserve the wrong meaning. The episode offers a practical handoff method built around intent, decisions, boundaries, examples, and feedback loops—without turning every conversation into bureaucracy. The goal is not perfect documentation, but fewer expensive misunderstandings between people who believe they already agreed.

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.

Business rules rarely arrive with an expiration date. A pricing threshold, approval step, customer classification, or reporting requirement may have been sensible when introduced, yet remain embedded in processes and systems long after its original purpose has disappeared. This episode examines how outdated decisions quietly become permanent operating constraints—and why removing them is harder than adding new functionality. From the business side, Mirko explores the pressure to preserve familiar rules because changing them feels risky, disruptive, or politically difficult. From the IT side, he follows how those rules spread across data models, integrations, permissions, reports, and undocumented workarounds. The central question is not simply whether a rule is still useful, but who is responsible for reviewing it and what evidence would justify retiring it. Listeners will learn how to distinguish genuine stability from historical inertia, identify rules that deserve review, and create lightweight review points before temporary assumptions become permanent architecture.

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.

Organizations often say that important decisions are shared. In practice, shared responsibility can mean that no one has the authority, context, or obligation to make the call and stand behind its consequences. This episode examines what happens when ownership is distributed across business sponsors, product teams, architects, operations, security, and vendors without a clear decision owner. From the business side, collaboration can feel safer and more inclusive. From the IT side, it can look like endless clarification, contradictory priorities, and designs built around assumptions. Mirko Peters explores how unowned decisions create delayed projects, duplicated controls, inconsistent customer experiences, and systems that nobody feels empowered to change. Using a generalized consulting example, the episode shows how to distinguish input, approval, execution, and accountability. Listeners will leave with practical questions for assigning ownership, recording decisions, handling legitimate disagreement, and revisiting choices without reopening every discussion. The goal is not to centralize every decision, but to make responsibility visible enough for strategy to become dependable execution.

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.

Organizations often treat KPIs as neutral instruments for observing performance. In practice, a metric can become an instruction. Once targets influence bonuses, escalation rules, prioritization, service levels, or investment decisions, they begin shaping business behavior—and the systems that support it. This episode examines how a seemingly reasonable measure can produce narrow optimization, customer friction, misleading dashboards, and IT requests that nobody intended to make. From the business perspective, metrics promise control and comparability. From the IT perspective, they create definitions, data dependencies, calculation logic, reporting obligations, and sometimes conflicting versions of reality. Mirko Peters explores the translation gap between measuring an outcome and managing a behavior, using a generalized consulting example involving speed, quality, and ownership. Listeners will learn how to test whether a KPI reflects the real goal, identify harmful side effects before they become embedded, and give business and IT a shared way to discuss measurement as a design decision—not merely a reporting task.

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.

Organizations often treat timing as an implementation detail: a nightly batch, a month-end cutoff, a two-day approval window, or a promise that a report will be ready by morning. But once those timing rules enter workflows, integrations, contracts, and customer expectations, the calendar becomes part of the operating model. This episode examines how business assumptions about speed, deadlines, and availability quietly become technical constraints—and how technical timing decisions reshape what the business can promise. Mirko Peters explores why a process that works in a workshop can fail at month-end, why “real time” means different things to different people, and how timing dependencies remain invisible until they create operational friction. Listeners will learn how to identify temporal assumptions early, distinguish true business deadlines from habits, and make explicit decisions about cutoffs, latency, scheduling, and recovery. The goal is not to make everything instant, but to ensure that the organization understands the consequences of the timing it chooses.

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.

Organizations often introduce exceptions with good reason: a customer needs special treatment, a deadline cannot move, or an existing system cannot support an important case. The trouble begins when a temporary workaround is repeated, remembered, and eventually built into everyday operations without anyone making an explicit decision. Business may see flexibility and responsiveness; IT may see undocumented rules, growing complexity, and support risk. This episode examines how exceptions travel from individual judgment into spreadsheets, approval chains, integrations, and application behavior. Mirko Peters uses a generalized consulting perspective to show why nobody necessarily caused the problem, yet everyone inherits it. Listeners will learn how to distinguish a legitimate exception from an emerging process, when to stop patching and make a policy decision, and how to create a lightweight exception review that preserves useful flexibility without allowing accidental architecture to take over.

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.

Organizations often treat work intake as administration: collect requests, add them to a backlog, and ask teams to work through the list. But the intake queue is where strategy becomes operational reality. It determines whose problems receive attention, which risks remain invisible, and whether urgent work continually displaces important work. From the business side, a request may appear to be a simple expression of value, urgency, or executive commitment. From the IT side, it arrives alongside dependencies, capacity limits, technical debt, regulatory obligations, and competing promises. This episode examines how poorly designed intake processes create the illusion of prioritization while quietly rewarding escalation, familiarity, and loudness. Mirko Peters explains the translation errors between business value and delivery effort, shows why ranking everything as high priority is not a decision, and offers a practical way to make trade-offs visible. Listeners will learn how to turn demand intake from a queue of wishes into a shared decision mechanism.

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.

Business leaders often describe a policy change as simple: one new approval step, a slightly different eligibility rule, or a revised deadline. IT may then respond with questions that sound disproportionate to the request. This episode explains why. Mirko Peters follows a minor policy decision across workflows, roles, data structures, interfaces, reporting, testing, training, and customer communication. The issue is not that IT resists change; it is that business meaning has physical consequences once it becomes system behavior. Using a generalized consulting example, the episode shows how teams can distinguish a genuinely local change from one with a wider blast radius. Listeners will learn how to ask better impact questions, identify hidden dependencies early, assign decision ownership, and choose sensible levels of analysis without turning every request into a lengthy project. The central lesson is practical: before asking whether a change is easy, ask what else currently depends on the rule being changed.

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.