Navigating Organizational Change and Securing Stakeholder Buy-In — Open Source CXO Ep. 11 | Active Logic
Organizational change is where leadership theories get tested against reality. In the first of two episodes with Jim Poteet, Senior Director of Revenue Cycle Development, Analytics & Middle Solutions at Oracle Health, the conversation focuses on the skills that separate leaders who can drive change from those who get consumed by it: building stakeholder buy-in, scaling teams without losing quality, and creating cultures of accountability in environments where the consequences of failure affect patient care.
Jim’s career arc — from individual contributor through progressive leadership roles to his current position overseeing development, analytics, and middleware solutions at Oracle Health — provides a longitudinal view of how leadership challenges evolve as scope and responsibility increase. The lessons he shares aren’t management theory; they’re the product of navigating real organizational complexity at one of the largest healthcare technology companies in the world.
Key Insight: Leadership Development as a Career-Long Investment
Jim’s path to senior leadership wasn’t a straight line, and that’s the point. He describes a career progression marked by deliberate skill-building: seeking out projects that stretched his capabilities, volunteering for cross-functional initiatives that expanded his organizational understanding, and actively pursuing mentorship from leaders he admired.
The common mistake in leadership development is treating it as a destination rather than an ongoing practice. Engineers who aspire to leadership often focus on technical credibility — “I need to be the best architect before I can lead architects” — while underinvesting in the communication, influence, and organizational skills that leadership actually requires.
Jim’s advice is practical: start leading before you have the title. Take ownership of cross-team coordination. Facilitate meetings. Mentor junior engineers. Build relationships outside your immediate team. These activities develop leadership muscles that can’t be built from a management book, and they make you visible to the people who make promotion decisions. For engineers building careers in software development, the transition from individual contributor to leader starts well before the title changes.
Key Insight: Securing Stakeholder Buy-In for Large Initiatives
Getting stakeholder buy-in is one of the most critical and least taught skills in technology leadership. Jim describes the dynamics at Oracle Health, where initiatives affect multiple departments, require significant investment, and compete with other priorities for executive attention.
The first principle: understand what each stakeholder cares about. Technical leaders tend to present initiatives in technical terms — architecture improvements, performance gains, technical debt reduction. But stakeholders outside engineering care about business outcomes: revenue impact, risk reduction, customer satisfaction, regulatory compliance. The same initiative needs to be framed differently for the CTO, the CFO, and the Chief Medical Officer.
The second principle: quantify the cost of inaction. Stakeholders who are reluctant to approve a new initiative are often comparing it to the status quo, which they perceive as free. Jim describes how making the cost of the current state visible — in terms of maintenance burden, incident frequency, opportunity cost, and competitive risk — shifts the conversation from “why should we do this?” to “can we afford not to?”
The third principle: build allies before the meeting. The formal decision-making moment should be the end of the persuasion process, not the beginning. Jim describes the groundwork that precedes successful proposals: one-on-one conversations with key stakeholders, incorporating their feedback into the proposal, and ensuring that no one in the decision-making room is hearing the idea for the first time.
Key Insight: Scaling High-Performing Teams
Jim manages a substantial organization within Oracle Health, and the conversation addresses the challenge of maintaining team quality as teams grow. The pattern he describes is familiar: a small, high-performing team achieves strong results, leadership decides to scale the approach, and the scaling process dilutes the very qualities that made the original team effective.
The root cause is usually a failure to distinguish between what made the small team work and what needs to change at larger scale. Small teams benefit from implicit communication — everyone knows what everyone else is working on, norms are understood without documentation, and coordination happens organically. These mechanisms break down as teams grow, and leaders who don’t replace them with explicit processes and structures watch performance degrade despite having more people.
Jim’s approach involves defining team operating principles explicitly, documenting decision-making frameworks, and creating communication structures that scale. He also emphasizes the importance of mid-level leadership: as organizations grow, the quality of team leads and engineering managers becomes the primary determinant of overall team quality. Investing in developing these mid-level leaders is the highest-leverage activity a senior leader can perform.
Key Insight: Team Culture and the 6 AM Tailgate
Jim shares a distinctive example of team culture: morning tailgates before major releases. The specific practice matters less than what it represents — a team that genuinely enjoys working together and marks significant milestones in ways that reinforce team identity and shared purpose.
Culture at this level isn’t manufactured by HR or mandated by leadership. It emerges from genuine connection between team members who respect each other’s capabilities and share a sense of mission. Jim’s role isn’t to create these moments but to create the conditions where they can happen: psychological safety, shared accountability, and a team composition where people genuinely complement each other’s strengths.
The practical lesson for leaders: you can’t force culture, but you can kill it. Overloading teams, tolerating toxic behavior, or failing to celebrate wins all erode the organic cultural elements that make teams high-performing. Protecting the conditions for positive culture is as important as any technical decision.
Key Insight: Accountability in Regulated Industries
Healthcare technology operates under constraints that most software teams don’t face. Patient data is protected by HIPAA, clinical systems must meet certification requirements, and software errors can have direct patient safety implications. Jim discusses how these constraints shape accountability structures within his organization.
Accountability in this context isn’t about blame — it’s about traceability and learning. When something goes wrong (and in complex systems, things always go wrong), the organization needs to understand what happened, why it happened, and how to prevent recurrence. This requires a culture where people feel safe reporting errors and near-misses without fear of punishment.
Jim describes the balance: high standards for quality and process adherence, combined with psychological safety that encourages transparency. Teams that fear punishment hide problems until they become crises. Teams that operate with genuine accountability surface issues early, when they’re cheapest to fix. For organizations building cloud infrastructure and deploying systems in regulated environments, this cultural foundation directly affects operational reliability.
Takeaways
- Start leading before you have the title. Cross-functional visibility, mentoring, and coordination build leadership skills that books can’t teach.
- Frame initiatives in stakeholder terms. Technical leaders must translate technical value into business language for each audience.
- Quantify the cost of inaction. The status quo isn’t free — make its costs visible to shift the decision calculus.
- Invest in mid-level leadership. As organizations scale, the quality of team leads and engineering managers determines overall team quality.
- Protect the conditions for culture. You can’t manufacture positive culture, but you can destroy it through overwork, toxicity, or neglect.
- Build accountability through safety, not fear. Teams that feel safe reporting problems catch issues early; teams that fear punishment hide them.
