AI Assisted Coding: Transactional AI Development - Commit, Validate, and Rollback With Sergey Sergyenko

AI Assisted Coding: Transactional AI Development - Commit, Validate, and Rollback With Sergey Sergyenko

AI Assisted Coding: Treating AI Like a Junior Engineer - Onboarding Practices for AI Collaboration

In this special episode, Sergey Sergyenko, CEO of Cybergizer, shares his practical framework for AI-assisted development built on transactional models, Git workflows, and architectural conventions. He explains why treating AI like a junior engineer, keeping commits atomic, and maintaining rollback strategies creates production-ready code rather than just prototypes.

Vibecoding: An Automation Design Instrument

"I would define Vibecoding as an automation design instrument. It's not a tool that can deliver end-to-end solution, but it's like a perfect set of helping hands for a person who knows what they need to do."

Sergey positions vibecoding clearly: it's not magic, it's an automation design tool. The person using it must know what they need to accomplish—AI provides the helping hands to execute that vision faster. This framing sets expectations appropriately: AI speeds up development significantly, but it's not a silver bullet that works without guidance. The more you practice vibecoding, the better you understand its boundaries. Sergey's definition places vibecoding in the evolution of development tools: from scaffolding to co-pilots to agentic coding to vibecoding. Each step increases automation, but the human architect remains essential for providing direction, context, and validation.

Pair Programming with the Machine

"If you treat AI as a junior engineer, it's very easy to adopt it. Ah, okay, maybe we just use the old traditions, how we onboard juniors to the team, and let AI follow this step."

One of Sergey's most practical insights is treating AI like a junior engineer joining your team. This mental model immediately clarifies roles and expectations. You wouldn't let a junior architect your system or write all your tests—so why let AI? Instead, apply existing onboarding practices: pair programming, code reviews, test-driven development, architectural guidance. This approach leverages Extreme Programming practices that have worked for decades. The junior engineer analogy helps teams understand that AI needs mentorship, clear requirements, and frequent validation. Just as you'd provide a junior with frameworks and conventions to follow, you constrain AI with established architectural patterns and framework conventions like Ruby on Rails.

The Transactional Model: Atomic Commits and Rollback

"When you're working with AI, the more atomic commits it delivers, more easy for you to kind of guide and navigate it through the process of development."

Sergey's transactional approach transforms how developers work with AI. Instead of iterating endlessly when something goes wrong, commit frequently with atomic changes, then rollback and restart if validation fails. Each commit should be small, independent, and complete—like a feature flag you can toggle. The commit message includes the prompt sequence used to generate the code and rollback instructions.

This approach makes the Git repository the context manager, not just the AI's memory. When you need to guide AI, you can reference specific commits and their context. This mirrors trunk-based development practices where teams commit directly to master with small, verified changes. The cost of rollback stays minimal because changes are atomic, making this strategy far more efficient than trying to fix broken implementations through iteration.

Context Management: The Weak Point and the Solution

"Managing context and keeping context is one of the weak points of today's coding agents, therefore we need to be very mindful in how we manage that context for the agent."

Context management challenges current AI coding tools—they forget, lose thread, or misinterpret requirements over long sessions. Sergey's solution is embedding context within the commit history itself. Each commit links back to the specific reasoning behind that code: why it was accepted, what iterations it took, and how to undo it if needed. This creates a persistent context trail that survives beyond individual AI sessions. When starting new features, developers can reference previous commits and their context to guide the AI. The transactional model doesn't just provide rollback capability—it creates institutional memory that makes AI progressively more effective as the codebase grows.

TDD 2.0: Humans Write Tests, AI Writes Code

"I would never allow AI to write the test. I would do it by myself. Still, it can write the code."

Sergey is adamant about roles: humans write tests, AI writes implementation code. This inverts traditional TDD slightly—instead of developers writing tests then code, they write tests and AI writes the code to pass them. Tests become executable requirements and prompts. This provides essential guardrails: AI can iterate on implementation until tests pass, but it can't redefine what "passing" means. The tests represent domain knowledge, business requirements, and validation criteria that only humans should control. Sergey envisions multi-agent systems where one agent writes code while another validates with tests, but critically, humans author the original test suite. This TDD 2.0 framework (a talk Sergey gave at the Global Agile Summit) creates a verification mechanism that prevents the biggest anti-pattern: coding without proper validation.

The Two Cardinal Rules: Architecture and Verification

"I would never allow AI to invent architecture. Writing AI agentic coding, Vibecoding, whatever coding—without proper verification and properly setting expectations of what you want to get as a result—that's the main mistake."

Sergey identifies two non-negotiables. First, never let AI invent architecture. Use framework conventions (Rails, etc.) to constrain AI's choices. Leverage existing code generators and scaffolding. Provide explicit architectural guidelines in planning steps. Store iteration-specific instructions where AI can reference them. The framework becomes the guardrails that prevent AI from making structural decisions it's not equipped to make. Second, always verify AI output. Even if you don't want to look at code, you must validate that it meets requirements. This might be through tests, manual review, or automated checks—but skipping verification is the fundamental mistake. These two rules—human-defined architecture and mandatory verification—separate successful AI-assisted development from technical debt generation.

Prototype vs. Production: Two Different Workflows

"When you pair as an architect or a really senior engineer who can implement it by himself, but just wants to save time, you do the pair programming with AI, and the AI kind of ships a draft, and rapid prototype."

Sergey distinguishes clearly between prototype and production development. For MVPs and rapid prototypes, a senior architect pairs with AI to create drafts quickly—this is where speed matters most. For production code, teams add more iterative testing and polishing after AI generates initial implementation. The key is being explicit about which mode you're in. The biggest anti-pattern is treating prototype code as production-ready without the necessary validation and hardening steps. When building production systems, Sergey applies the full transactional model: atomic commits, comprehensive tests, architectural constraints, and rollback strategies. For prototypes, speed takes priority, but the architectural knowledge still comes from humans, not AI.

The Future: AI Literacy as Mandatory

"Being a software engineer and trying to get a new job, it's gonna be a mandatory requirement for you to understand how to use AI for coding. So it's not enough to just be a good engineer."

Sergey sees AI-assisted coding literacy becoming as fundamental as Git proficiency. Future engineering jobs will require demonstrating effective AI collaboration, not just traditional coding skills. We're reaching good performance levels with AI models—now the challenge is learning to use them efficiently. This means frameworks and standardized patterns for AI-assisted development will emerge and consolidate. Approaches like AAID, SpecKit, and others represent early attempts to create these patterns. Sergey expects architectural patterns for AI-assisted development to standardize, similar to how design patterns emerged in object-oriented programming. The human remains the bottleneck—for domain knowledge, business requirements, and architectural guidance—but the implementation mechanics shift heavily toward AI collaboration.

Resources for Practitioners

"We are reaching a good performance level of AI models, and now we need to guide it to make it impactful. It's a great tool, now we need to understand how to make it impactful."

Sergey recommends Obie Fernandez's work on "Patterns of Application Development Using AI," particularly valuable for Ruby and Rails developers but applicable broadly. He references Andrey Karpathy's original vibecoding post and emphasizes Extreme Programming practices as foundational. The tools he uses—Cursor and Claude Code—support custom planning steps and context management. But more important than tools is the mindset: we have powerful AI capabilities now, and the focus must shift to efficient usage patterns. This means experimenting with workflows, documenting what works, and sharing patterns with the community. Sergey himself shares case studies on LinkedIn and travels extensively speaking about these approaches, contributing to the collective learning happening in real-time.

About Sergey Sergyenko

Sergey is the CEO of Cybergizer, a dynamic software development agency with offices in Vilnius, Lithuania. Specializing in MVPs with zero cash requirements, Cybergizer offers top-tier CTO services and startup teams. Their tech stack includes Ruby, Rails, Elixir, and ReactJS.

Sergey was also a featured speaker at the Global Agile Summit, and you can find his talk available in your membership area. If you are not a member don't worry, you can get the 1-month trial and watch the whole conference. You can cancel at any time.

You can link with Sergey Sergyenko on LinkedIn.

Avsnitt(200)

Product Owner Patterns - From Absent to Exceptional | Salum Abdul-Rahman

Product Owner Patterns - From Absent to Exceptional | Salum Abdul-Rahman

Salum Abdul-Rahman: Learning to Communicate Value in Public and Non-Profit Sectors' Product Development Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: The Systematic Value Communicator Salum describes working with a Product Owner who had a PhD in data science on a public sector visualization project. This exceptional PO was extremely systematic in working with stakeholders and possessed a unique ability to bridge abstract concepts with concrete implementations. In the public sector, where monetary feedback is absent, this PO excelled at thinking about value achievement and communicating it effectively to the team. They had the magical capability to involve stakeholders while demystifying complex requirements, helping the team understand not just engagement metrics but how their work would change society and the world. The Bad Product Owner: The Absentee Specialist The most common anti-pattern Salum encounters is the absentee Product Owner - typically a specialist assigned to the PO role while maintaining their full-time job as a domain expert. With only 10-20% time allocation, these POs lack the capacity to fulfill their responsibilities effectively. They often don't have the time or knowledge to develop essential PO skills, requiring extensive hand-holding to understand even basic concepts like user stories. Salum's approach involves booking time directly in their calendar for backlog refinement sessions and providing comprehensive guidance to help them understand the role, though this intensive support is necessary due to their limited availability for skill development. In this segment, we refer to the concept of 'enshitification' by Cory Doctorow, and refer to Tom Gilb's bonus episode on the Scrum Master Toolbox Podcast. Self-reflection Question: How do you ensure your Product Owner has both the time allocation and skill development needed to truly serve the team and stakeholders effectively? [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Salum Abdul-Rahman Salum is an agile coach at Reaktor and experienced leader driving sustainable knowledge work. He is passionate about enabling teams to work with complexity and conflicts. Salum builds communities in and outside of work and has 18 years of experience working with software mostly as a consultant with the public sector. You can link with Salum Abdul-Rahman on LinkedIn.

29 Aug 18min

The SECI Model of Knowledge Management Applied to Team Retrospectives | Salum Abdul-Rahman

The SECI Model of Knowledge Management Applied to Team Retrospectives | Salum Abdul-Rahman

Salum Abdul-Rahman: The SECI Model of Knowledge Management Applied to Team Retrospectives Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Salum explains how the key role for Scrum Masters is to help teams develop themselves to the point where they can learn and grow without constant guidance. Success means building team resilience and operational capability while knowing when to step back. He emphasizes the importance of recalibration workshops to maintain shared understanding and the balance between supporting teams and challenging them to become self-sufficient. When teams reach this level of maturity, Scrum Masters can focus their efforts elsewhere, knowing the team has developed the capability to continue evolving independently. Featured Retrospective Format for the Week: The 5-Stage Retro Format From the book "Agile Retrospectives," this format captures the complete learning process and aligns beautifully with knowledge management principles. Salum connects the three central phases of this format to the SECI model of knowledge management, particularly referencing Nonaka and Takeuchi's work in "The Knowledge Creating Company." This retrospective structure helps teams create new knowledge and behavioral change by following a systematic approach that transforms individual insights into collective team learning and action. In this segment, we also refer to the seminal article by Takeuchi and Nonaka: "The New New Product Development Game", which originated the work on Scrum as a framework. Self-reflection Question: How do you recognize when your team has developed enough self-sufficiency that your role as facilitator can evolve or step back? [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Salum Abdul-Rahman Salum is an agile coach at Reaktor and experienced leader driving sustainable knowledge work. He is passionate about enabling teams to work with complexity and conflicts. Salum builds communities in and outside of work and has 18 years of experience working with software mostly as a consultant with the public sector. You can link with Salum Abdul-Rahman on LinkedIn.

28 Aug 14min

From Lunch Conversations to Company-Wide Change—The Power of Creating Communities of Practice | Salum Abdul-Rahman

From Lunch Conversations to Company-Wide Change—The Power of Creating Communities of Practice | Salum Abdul-Rahman

Salum Abdul-Rahman: From Lunch Conversations to Company-Wide Change—The Power of Creating Communities of Practice Within Organizations Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Salum shares how he organically built an Agile community within his company by recognizing a shared need for discussion and learning. Starting as a software developer who took on Scrum Master tasks, he felt isolated in his Agile journey. Rather than waiting for formal training or external events, he sent out a simple invite on the company Slack for a lunch discussion during a work day. People showed up, and what began as informal conversations about different approaches to Scrum and Kanban evolved into monthly gatherings. Over time, this grassroots community grew to organize company-wide events and even found new leadership when Salum moved on, demonstrating the power of identifying shared needs and taking initiative to address them. Self-reflection Question: What shared learning needs exist in your organization that you could address by simply reaching out and organizing informal discussions? [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Salum Abdul-Rahman Salum is an agile coach at Reaktor and experienced leader driving sustainable knowledge work. He is passionate about enabling teams to work with complexity and conflicts. Salum builds communities in and outside of work and has 18 years of experience working with software mostly as a consultant with the public sector. You can link with Salum Abdul-Rahman on LinkedIn.

27 Aug 12min

From Isolation to Integration—Rebuilding Agile Team Connection For Remote Teams | Salum Abdul-Rahman

From Isolation to Integration—Rebuilding Agile Team Connection For Remote Teams | Salum Abdul-Rahman

Salum Abdul-Rahman: From Isolation to Integration—Rebuilding Agile Team Connection For Remote Teams Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Salum describes working with a grocery ecommerce team during COVID that fell into the trap of prioritizing individual convenience over team collaboration. Remote work led team members to design their work around personal preferences, with the lead developer becoming increasingly isolated and unresponsive to team communication. This anti-pattern of "what works for me" over "what works for the whole team" created significant dysfunction. Despite management intervention, the situation required creative solutions like organizing face-to-face sessions and shared working sessions with digital whiteboards to rebuild team cohesion. Featured Book of the Week: Agile Retrospectives One of the most important roles of Scrum Masters is to help teams develop themselves. Salum emphasizes that you can't tell the team what to do - you have to help them discover it themselves. "Agile Retrospectives" provides the foundation for running meaningful retrospectives that become the key tool for team self-development. The book's emphasis on variation and building retrospectives to match your team's needs and maturity level makes it essential for empowering teams to grow and evolve continuously. Self-reflection Question: How might your team's current work arrangements prioritize individual convenience over collective effectiveness, and what steps could you take to shift this balance? [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Salum Abdul-Rahman Salum is an agile coach at Reaktor and experienced leader driving sustainable knowledge work. He is passionate about enabling teams to work with complexity and conflicts. Salum builds communities in and outside of work and has 18 years of experience working with software mostly as a consultant with the public sector. You can link with Salum Abdul-Rahman on LinkedIn.

26 Aug 17min

The Expert Who Couldn't Connect: An Agile Team Integration Challenge | Salum Abdul-Rahman

The Expert Who Couldn't Connect: An Agile Team Integration Challenge | Salum Abdul-Rahman

Salum Abdul-Rahman: The Expert Who Couldn't Connect: An Agile Team Integration Challenge Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Salum shares a challenging situation where a software architect with deep expertise struggled to integrate with the team. Despite the architect's technical knowledge, his expert-based communication style and inability to justify reasoning created friction with other developers. The conflict escalated when the architect disengaged from teamwork and ultimately left the company. This experience highlights the importance of understanding organizational dynamics in large corporations and recognizing when separation might be the best solution for everyone involved. In this episode, we refer to Nonviolent Communication, a topic we've discussed often here on the podcast. Self-reflection Question: How do you balance respecting expertise while ensuring all team members communicate in ways that foster collaboration rather than create hierarchies? [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Salum Abdul-Rahman Salum is an agile coach at Reaktor and experienced leader driving sustainable knowledge work. He is passionate about enabling teams to work with complexity and conflicts. Salum builds communities in and outside of work and has 18 years of experience working with software mostly as a consultant with the public sector. You can link with Salum Abdul-Rahman on LinkedIn.

25 Aug 14min

BONUS: Captain David Marquet's Guide to Becoming Your Own Best Coach

BONUS: Captain David Marquet's Guide to Becoming Your Own Best Coach

BONUS: Captain David Marquet's Guide to Becoming Your Own Best Coach In this BONUS episode, we dive deep into Captain David Marquet's latest book "Distancing: How Great Leaders Reframe to Make Better Decisions." Captain Marquet, renowned for transforming the USS Santa Fe from the worst-performing submarine to the best in the fleet, shares powerful insights on psychological distancing and how stepping outside ourselves can dramatically improve our decision-making abilities. Make sure you also check the previous episode with Captain Marquet, where we discuss the key lessons from his book: Turn The Ship Around! A very often referred book on the Scrum Master Toolbox Podcast. The Genesis of Distancing "What I really needed was people to think, not just comply, not just do what they were told." Captain Marquet traces the origins of his distancing concept back to his submarine experience. After realizing that giving orders gave people "a pass on thinking," he developed a system where crew members would say "I intend to..." instead of waiting for commands. However, he noticed that officers would sometimes make decisions that were good for their department but not optimal for the submarine as a whole. This led him to ask different questions - like having the engineer sit in the captain's chair and think from that perspective. The breakthrough came when he started asking himself, "What would my six-month-from-now self want me to do today?" The Three B's of Better Decision Making "The problem with your decision making isn't gathering more market data. The problem is your internal, your egoic biases that just come from the fact that you view the decision from inside your own head." Marquet introduces the "3 B's of better decision making": Be someone else, be somewhere else, be sometime else. These psychological distancing techniques help overcome the limitations of our "immersed self" - the version of us trapped in immediate pressures, deadlines, and ego-driven concerns. When we distance ourselves temporally (thinking as our future self), socially (thinking as someone else), or spatially (imagining being somewhere else), we access what psychologists call our "distanced self," which aligns more closely with our ideal self and core values. The Jeff Bezos Example "When I'm 80, when am I going to regret more? Am I going to regret trying this idea and failing or not trying the idea?" Marquet shares how Jeff Bezos used temporal distancing when deciding whether to leave his Wall Street job to start Amazon. By imagining himself at 80 looking back, Bezos was able to see past immediate concerns like his upcoming bonus and rent payments to focus on what would truly matter in the long term. This shift in perspective transforms how our brain processes decisions - from viewing them as "scary change" to considering them through the lens of potential regret. Practical Applications for Teams "I want you to imagine that a team in Singapore is going to work on the same kind of project next month. What would we want them to know?" The distancing technique has powerful applications for team retrospectives and decision-making. Instead of asking "What could we have done better?" (which triggers defensiveness), Marquet suggests reframing as helping a future team in another location. This approach employs all three B's simultaneously: Be someone else: Helping another team rather than critiquing yourself Be sometime else: Focusing on future improvement rather than past mistakes Be somewhere else: Imagining the team in a different location removes personal attachment Becoming Your Own Coach "You become your own friend, you become your own coach." Marquet emphasizes that leaders cannot effectively coach others until they learn to coach themselves. He challenges leaders who want their teams to change by asking, "What have you changed recently?" The coach perspective provides the elevated view needed to see the whole field rather than being immersed in the immediate action. Like a sports coach who doesn't feel the hits but sees the strategy, our "coach self" can provide objective guidance to our "player self." The Language of Leadership "The people who said 'you can do it' exerted more energy and felt better than the people who said 'I can do it.'" Building on his previous work in "Leadership is Language," Marquet demonstrates how changing from first-person to second or third-person language creates psychological distance. Studies show that athletes performing endurance tests while saying "you can do it" outperformed those saying "I can do it." This simple language shift helps separate us from the immersed self and provides a slight but meaningful perspective advantage. The Intel Transformation Story "What if we got fired? And the board brought in new people to run the company. What would the new people do?" Marquet shares the pivotal moment when Intel founders Gordon Moore and Andy Grove used distancing to make the crucial decision to abandon memory chips for microprocessors. For a year, they couldn't make this decision because their identity was tied to being "memory chip makers." Only when Grove asked Moore to imagine what new leadership would do were they able to immediately see the obvious answer: focus on microprocessors. This decision saved Intel and created the company we know today. Stopping Time: Planning the Pause "The best thing is you have to plan the pauses. The best case is when you plan the pause ahead of time." Marquet explains that once we're in our reactive, immersed state, it's nearly impossible to climb out without System 2 override. The solution is to schedule pauses proactively. When teams know there will be scheduled reflection points, they're more willing to commit to execution while also noting areas for improvement. This is why agile methodologies are so effective - they build in regular pause points for reflection and course correction. Overcoming Defensive Reactions "Your brain will curate the input - it will always choose to pay attention to things that prove you're right and ignore things that prove you wrong." The immersed self creates defensive reactions during evaluations, retrospectives, or any situation involving performance assessment. Our brains naturally filter information to support our existing self-image, remembering successes while forgetting failures. Distancing techniques help bypass these defensive mechanisms by removing the ego from the equation, allowing for more objective analysis and better decision-making. Acting Your Way to New Thinking "We act our way to new thinking. You want to do different things. We act your way to a new mindset. You don't mindset your way to new actions." Marquet concludes with a crucial insight about change: behavior change leads to mindset change, not the other way around. Rather than trying to convince people to think differently, leaders should focus on creating small, actionable changes that gradually shift thinking patterns. His "Leadership Nudges" concept embodies this approach, offering brief, practical tools that teams can implement immediately. About Captain David Marquet Captain David Marquet, a former U.S. Navy submarine commander, revolutionized leadership by empowering his crew to become leaders themselves. Through his Intent-Based Leadership® model, he transformed the USS Santa Fe from the worst-performing submarine to the best in the fleet. Today, he inspires organizations worldwide to cultivate leaders at every level. You can connect with Captain David Marquet on LinkedIn and follow him on his website at davidmarquet.com. You can also explore his YouTube channel "Leadership Nudges" for a library of over 500 short leadership videos.

24 Aug 42min

BONUS The Platform-as-Product Revolution: How to Turn Your Biggest Cost Center Into Your Secret Weapon | Alvaro Lorente

BONUS The Platform-as-Product Revolution: How to Turn Your Biggest Cost Center Into Your Secret Weapon | Alvaro Lorente

BONUS: The Platform-as-Product Revolution: How to Turn Your Biggest Cost Center Into Your Secret Weapon With Alvaro Lorente In this BONUS episode we explore a topic that's creating a lot of discussion—and sometimes confusion—in the software community: Platform Teams vs DevOps. In this conversation, we dive into Alvaro Lorente's journey from delivery teams to platform leadership, exploring how to treat platforms as products, avoid common pitfalls, and build bridges between engineering and product leadership. The Evolution from DevOps Role to Platform Team "DevOps is a culture, not a role." Alvaro's journey into platform work began when he joined a company where the infrastructure team was left behind and struggling with traditional DevOps approaches. Initially, they had a single DevOps person who became a bottleneck rather than an enabler. This experience highlighted a fundamental misunderstanding that many organizations face—treating DevOps as a job title rather than a cultural shift toward collaboration and shared responsibility. The team experimented with a "DevOps buddy" approach, placing experienced individuals within each delivery team, before eventually consolidating into a dedicated platform team with the clear intention of treating it as a product-focused unit. Platform as a Product: A Scaling Strategy "Platform as a product is a scaling strategy. Look for common problems that you can then solve once, and serve many." The concept of treating platforms as products emerged from recognizing that feature delivery teams have continuity and ongoing needs that a platform team should serve. Rather than solving their own problems first, successful platform teams focus on making other teams' work easier and more comfortable while managing costs effectively. This approach requires identifying common problems across multiple teams and creating solutions that can be implemented once but serve many. The key insight is that platform teams exist to facilitate the delivery of value in a scalable way for other teams, not to pursue their own technical interests. Understanding Your Customer and Validating Value "I want to see platform team members talking to their customers. Understand their pains, and what they struggle with." Effective platform teams operate like any other product team by actively listening to their customer-teams rather than pushing ideas onto them. This means platform team members should regularly engage with their internal customers to understand pain points and struggles. Success requires defining clear KPIs for the platform and focusing on the quality of deliverables including release notes, demos, bug fixing processes, and feature prioritization. The validation comes from observing whether teams willingly adopt platform features rather than being mandated to use them. Building Bridges with Product Leadership "Focus on the key impact and value that the platform team can bring to the company." Making the case for investing product talent in platform teams requires demonstrating concrete business value. This includes quantifying how many incidents are being resolved faster or prevented entirely, and highlighting the money saved through internal platform development versus external solutions. Platform work offers excellent growth opportunities for Product Owners, serving as a training ground for product thinking and stakeholder management. The focus should always be on measurable impact rather than technical complexity. Avoiding Common Platform Team Traps "Don't just start working on what you think is important! Start with the Product process, listen to the client-teams, and help them directly." When standing up a platform team, several critical mistakes can derail success. The most important trap to avoid is immediately diving into what the platform team thinks is important without first understanding customer needs. Platform teams should resist delivery pressure that might compromise quality and never mandate adoption of their features—teams should want to use what the platform provides. Treating the platform as a genuine product with quality standards is essential, and leaders should view the creation of a platform team as the beginning of a change management process rather than just a technical reorganization. Resources and Continuous Learning "One size does NOT fit all!" For teams looking to improve their platform work, Alvaro recommends Camille Fournier's work on platform teams and resources focused on "The value of product thinking in platform teams." The key is to get experiments running within your team and recognize that there's no universal solution—each organization must find its own path based on its unique context and needs. About Alvaro Lorente Currently Director of Engineering at Voxel (an Amadeus company), Alvaro is a software engineer who has grown in the people leadership path, experimenting with everything from product development to startups and open source projects. He embraces the idea of being a jack of all trades, helping wherever needed to drive value and impact. You can connect with Alvaro Lorente on LinkedIn and follow his insights through his Substack newsletter titled Leads Horizons.

23 Aug 37min

Truth vs. Fiction - The Power of Transparency in Product Ownership | Irene Castagnotto

Truth vs. Fiction - The Power of Transparency in Product Ownership | Irene Castagnotto

Irene Castagnotto: Building Bridges—How Great Product Owners Create Team Alignment Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: Building Trust Through Transparency and Purpose Irene emphasizes that exceptional Product Owners excel at building trust with their teams by consistently sharing the "why" behind decisions and features. They trust their teams completely and ensure that team members understand the purpose and reasoning behind every request. This transparency creates a foundation of mutual trust where teams feel confident in the Product Owner's direction. Great Product Owners use moments when features don't work as expected as opportunities to explore and reinforce the underlying purpose, turning potential setbacks into learning experiences that strengthen team understanding and alignment. The Bad Product Owner: When Stories Replace Truth Irene witnessed a Product Owner who, when facing difficult client conversations without positive information to share, chose to "make up stories" rather than being transparent about challenges. This lack of honesty led to delivering something the client couldn't accept, resulting in an angry client during the demo. This anti-pattern of using "good words" instead of honest communication ultimately damages client relationships and team credibility. The lesson learned: Product Owners must be transparent with clients about what is and isn't possible, even when the news is difficult to deliver. Self-reflection Question: How do you balance protecting your team from client frustration while maintaining the transparency necessary for successful product development? [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Irene Castagnotto Irene, a Gen Z Italian Scrum Master, began her Agile journey at a young age. With a positive and passionate approach, she aims to help her generation navigate the world of work with confidence and serenity, while supporting teams in unlocking their full potential. You can link with Irene Castagnotto on LinkedIn.

22 Aug 16min

Populärt inom Politik & nyheter

aftonbladet-krim
svenska-fall
motiv
p3-krim
flashback-forever
fordomspodden
rss-viva-fotboll
rss-krimstad
aftonbladet-daily
rss-sanning-konsekvens
rss-vad-fan-hande
spar
rss-krimreportrarna
rss-frandfors-horna
blenda-2
olyckan-inifran
dagens-eko
krimmagasinet
rss-flodet
rss-expressen-dok