Beyond AI Code Assistants: How Moldable Development Answers Questions AI Can't | Tudor Girba

Beyond AI Code Assistants: How Moldable Development Answers Questions AI Can't | Tudor Girba

AI Assisted Coding: Beyond AI Code Assistants: How Moldable Development Answers Questions AI Can't With Tudor Girba

In this BONUS episode, we explore Moldable Development with Tudor Girba, CEO of feenk.com and creator of the Glamorous Toolkit. We dive into why developers spend over 50% of their time reading code—not because they want to, but because they lack the answers they need. Tudor shares how building contextual tools can transform software development, making systems truly understandable and enabling decisions at the speed of thought.

The Hidden System: A Telco's Three-Year Quest

"They had a system consisting of five boxes, but they could only enumerate four. If this is your level of awareness about what is reality around you, you have almost no chance of systematically affecting that reality."

Tudor opens with a striking case study from a telecommunications company that spent three years and hundreds of person-years trying to optimize a data pipeline. Despite massive effort and executive mandate, the pipeline still took exactly one day to process data—no improvement whatsoever. When Tudor's team investigated, they asked for an architecture diagram. The team drew four boxes representing their system. But when Tudor's team started building tools to mirror this architecture back from the actual code, they discovered something shocking: there was an entire fifth system between the first and second boxes that nobody knew existed. This missing system was likely the bottleneck they'd been trying to optimize for three years.

Why Reading Code Doesn't Scale

"Developers spend more than 50% of their time reading code. The problem is that our systems are typically larger than anyone can read, and by the time you finish reading, the system has already changed many times."

The real issue isn't the time spent reading—it's that reading is the most manual, least scalable way to extract information from systems. When developers read code, they're actually trying to answer questions so they can make decisions. But a 250,000-line system would take one person-month to read at high speed, and the system changes constantly during that time. This means everything you learned yesterday becomes merely a hypothesis, not a reliable answer. The fundamental problem is that we cannot perceive anything in a software system except through tools, yet we've never made how we read code an explicit, optimizable activity.

The Context Problem: Why Generic Tools Fail

"Software is highly contextual, which means we can predict classes of problems people will have, but we cannot predict specific problems people will have."

Tudor draws a powerful parallel with testing. Nobody downloads unit tests from the web and applies them to their system—that would be absurd. Instead, we download test frameworks and build tests contextually for our specific system, encoding what's valuable about our particular business logic. Yet for almost everything else in software development, we download generic tools and expect them to work. This is why teams have tens of thousands of static analysis warnings they ignore, while a single failing test stops deployment. The test encodes contextual value; the generic warning doesn't. Moldable Development extends this principle: every question about your system should be answered by a contextual tool you build for that specific question.

Tools That Mirror Your Mental Model

"Whatever you draw on the whiteboard—that's your mental model. But as soon as the system exists, we want the system to mirror you back that thing. We make it the job of the system to show our mental model back to us."

When someone draws an architecture diagram on a whiteboard, they're not documenting the system—they're documenting their beliefs about the system. The diagram represents wishes when drawn before the system exists, but beliefs when drawn after. Moldable Development flips this: instead of humans reading code and creating approximations, the system itself generates the visualization directly from the actual code. This eliminates the layers of belief and inference. Whether you're looking at high-level architecture, data lineage across multiple technologies, performance bottlenecks, or business domain structure, you build small tools that extract and present exactly the information you need from the system as it actually is.

The Test-Driven Development Parallel

"Testing was a way to find some kind of class of answers. But there are many other questions we have, and the question is: is there a systematic way to approach arbitrary questions?"

Tudor explains that Moldable Development applies test-driven development principles to all forms of system understanding. Just as we write tests after we understand the functionality we need, we build visualization and analysis tools after we understand the questions we need answered. Both approaches share key characteristics: they're built contextually for the specific system, created by developers during development, and composed of many small tools that collectively model the system. The difference is that TDD focuses on functional decomposition and known expectations, while Moldable Development addresses architecture, security, domain structure, performance, and any other perspective where functional tests aren't the most useful decomposition.

From Thousands of Features to Thousands of Tools

"In my development environment, I don't have features. I have thousands of tools that coexist. Development environments should be focused not on what exists out of the box, but on how quickly you can create a contextual tool."

Traditional development environments offer dozens of features—buttons, plugins, generic views. But Moldable Development environments contain thousands of micro-tools, each answering a specific question about a specific system. The key is making these tools composable and fast to create. Rather than building monolithic tools that try to handle every scenario, you build small inspectors that show one perspective on one object or concept. These inspectors chain together naturally as you drill down from high-level questions to detailed investigations. You might have one inspector showing test failures grouped by exception type, another showing PDF document comparisons, another showing cluster performance, and another showing memory usage—all coexisting and available when needed.

The Real Bottleneck To Learning A System: Time to the Next Question

"Once you do this, you will see that the interesting bottleneck is in the time to the next interesting question. This is by far the most interesting place to be spending energy."

When you commoditize access to answers through contextual tools, something remarkable happens: the bottleneck shifts from getting answers to asking better questions. Right now, because answers come so slowly through manual reading and analysis, we rarely exercise the skill of formulating good questions. We make decisions based on gut feelings and incomplete data because we can't afford to dig deeper. But when answers arrive at the speed of thought, you can explore, follow hunches, test hypotheses, and develop genuine insight. The conversation between person and system becomes fluid, enabling decision-making based on actual evidence rather than belief.

Moldable Development in Practice: The Lifeware Case

"They are investing in software engineering as their competitive advantage. They have 150,000 tests that would take 10 days to run on a single machine, but they run them in 16 minutes distributed across AWS."

Tudor shares a powerful case study of Lifeware, a life insurance software company that was featured in Kent Beck's "Test-Driven Development by Example" in 2002 with 4,000 tests. Today they have 150,000 tests and have fully adopted Moldable Development as their core practice. Their business model is remarkable: they take data from insurance companies, throw away the old systems, and reverse-engineer new systems by TDD-ing the business—replaying history to produce pixel-identical documents. They've deployed Glamorous Toolkit as their sole development environment across 100+ developers. Their approach demonstrates that Moldable Development isn't just a research concept but a practical competitive advantage that scales to large teams and complex systems.

Why AI Doesn't Solve This Problem

"When you ask AI, you will get exactly the same kind of answers. The answer comes quickly, but you will not know whether this is accurate, whether this represents the whole thing, and you definitely do not have an explanation as to why the answer is the way it is."

In the age of AI code assistants, it might seem like language models could solve the problem of understanding systems. But Tudor explains why they can't. When you ask an AI about your architecture, you get an opinion—fast but unverifiable. Just like asking a developer to draw the architecture on a whiteboard, you receive filtered information without knowing if it's complete or accurate. Moldable Development, by contrast, extracts answers deterministically from the actual system. Software systems have almost no ambiguity in meaning—they're mathematical, not linguistic. We don't need probabilistic interpretation of source code; we need precise extraction and presentation. The tools you build give you not just answers but explanations of how those answers were derived from the actual system state.

Scaling Through Language, Not Features

"You need a new kind of development environment where the goal is to create tools much quicker. You need some sort of language in which to express development environments."

The technical challenge of Moldable Development is enabling thousands of tools to coexist productively. This requires a fundamentally different approach to development environments. Instead of adding features—buttons and menu items that quickly become overwhelming—you need a language for expressing tools and a system for composing them. Glamorous Toolkit demonstrates this through its inspector architecture, where any object can define custom views that appear contextually. These views compose naturally as you navigate through your investigation, reusing earlier perspectives while adding new ones. The environment becomes a medium for tool creation, not just a collection of pre-built features.

Making the Invisible Visible

"We cannot perceive anything in a software system except through a tool. If that's so important, then the ability to control that shape is probably kind of important too."

Software has no inherent shape—it's just data. Every perception we have of it comes through some tool that renders it into a form we can reason about. This means tools aren't nice-to-have accessories; they're fundamental to our ability to work with software at all. The text editor showing code is a tool. The debugger showing variables is a tool. But these are generic tools built once and reused everywhere, which means they show generic perspectives. What if we could control the shape of our software as easily as we write it? What if the system could show us exactly the view we need for exactly the question we have? That's the promise of Moldable Development.

About Tudor Girba

Tudor Girba is CEO of feenk.com and creator of Moldable Development. He leads the team behind Glamorous Toolkit, a novel IDE that helps developers make sense of complex systems. His work focuses on transforming how teams understand, navigate, and modernize legacy software through custom, insightful tools. Tudor and Simon Wardley are writing a book about Moldable Development which you can get at: https://moldabledevelopment.com/, and read more about in this Medium article.

You can link with Tudor Girba on LinkedIn.

Jaksot(200)

The No-Scroll Bar Rule—Empowering PO's Through Constraints | Joel Bancroft-Connors

The No-Scroll Bar Rule—Empowering PO's Through Constraints | Joel Bancroft-Connors

Joel Bancroft-Connors: The No-Scroll Bar Rule—Empowering PO's Through Constraints 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 Collaborative Innovator Joel describes an exceptional Product Owner scenario at a large insurance organization where complementary skills created magic. Working with two different people - a business expert who understood insurance but lacked development knowledge, and a designer with user experience expertise - Joel suggested the designer take on the Product Owner role while collaborating closely with the business person. This collaboration between complementary skills produced outstanding results. The great Product Owner understood that their role wasn't to control every detail but to unleash developer creativity by providing problems and context rather than prescriptive solutions. Joel's approach of "give the developers a problem and a canvas" allowed the team to innovate while staying focused on customer needs. This Product Owner fostered innovation rather than preventing it, demonstrating how effective collaboration can transform product development. The Bad Product Owner: The Business Analyst That Couldn't Let Go Joel identifies a problematic anti-pattern: the Business Analyst who transitions to Product Owner but can't abandon their documentation-heavy approach. While Business Analysts can make excellent Product Owners with proper support, those who insist on documenting everything create communication bottlenecks and slow down delivery. This creates a "telephone game" effect between the BA/PO and developers. Joel encountered one such individual who would declare "the developers can't do that" without giving them the opportunity to explore solutions. Following his "no-scroll bar rule" for documentation, Joel emphasizes that Product Owners should provide just enough information to enable developer creativity, not overwhelming detail that stifles innovation. When the problematic BA was replaced with someone who understood customers and trusted developers, the team's innovation flourished. In this segment, we refer to the book Liftoff, by Larsen and Nies. Self-reflection Question: Are you enabling developer innovation by providing problems and context, or are you stifling creativity with excessive documentation and control? [Scrum Master Toolbox Podcast Recommends] 🚀 Global Agile Summit 2025 Join us in Tallinn, Estonia, from May 18th – 20th, 2025, for an event that will inspire, challenge, and equip you with real-world Agile success stories. 🌍 Connect with global Agile leaders. 💡 Learn practical strategies for impact. 🔥 Break free from Agile fatigue and become a Pragmatic Innovator Check Full Program [Scrum Master Toolbox Podcast Recommends] About Joel Bancroft-Connors Joel Bancroft-Connors is The Gorilla Coach — a Certified Scrum Trainer and Agile disruptor focused on sustainable value and effectiveness. With a background in product, project, and coaching, Joel blends sharp insights with practical tools to help teams thrive. He is a Miro power user and rocks curated classroom playlists. You can link with Joel Bancroft-Connors on LinkedIn.

6 Kesä 19min

Sustainable Value—Redefining Success Beyond Profit | Joel Bancroft-Connors

Sustainable Value—Redefining Success Beyond Profit | Joel Bancroft-Connors

Joel Bancroft-Connors: Sustainable Value—Redefining Success Beyond Profit 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. Joel has evolved his definition of Scrum Master success over time, moving beyond traditional metrics to focus on what truly matters: sustainable value delivery. While Agile principles clearly state the goal of delivering value continuously, Joel emphasizes that success isn't just about making profit - it's about creating sustainable profit through sustainable processes and people practices. He challenges Scrum Masters to consider their "people sustainability metric" and asks whether their approach supports long-term team health and organizational resilience. Joel's definition encompasses three pillars: delivering sustainable value, maintaining sustainable processes, and ensuring sustainability for people. This holistic view of success requires Scrum Masters to think beyond immediate outcomes and consider the long-term impact of their practices. In this segment, we refer to the book Turn the ship around! by David Marquet. Self-reflection Question: What is your people sustainability metric, and how are you measuring whether your Scrum practices support long-term team and organizational health? Featured Retrospective Format for the Week: Back to Basics Joel advocates for returning to the foundational retrospective format outlined in "Agile Retrospectives" by Derby and Larsen. Rather than getting caught up in complex or creative retrospective techniques, he emphasizes the power of following the basic steps: set the stage, gather data, generate insights, decide what to do, and close the retrospective. Joel stresses that there's an important arc to retrospectives that shouldn't be overlooked. By taking time to properly gather data and following the structured approach from the agile retrospectives book, teams can achieve more meaningful and actionable outcomes. Sometimes the most effective approach is simply executing the fundamentals exceptionally well. In this segment, we refer to the book Agile retrospectives, by Derby and Larsen. [Scrum Master Toolbox Podcast Recommends] 🚀 Global Agile Summit 2025 Join us in Tallinn, Estonia, from May 18th – 20th, 2025, for an event that will inspire, challenge, and equip you with real-world Agile success stories. 🌍 Connect with global Agile leaders. 💡 Learn practical strategies for impact. 🔥 Break free from Agile fatigue and become a Pragmatic Innovator Check Full Program [Scrum Master Toolbox Podcast Recommends] About Joel Bancroft-Connors Joel Bancroft-Connors is The Gorilla Coach — a Certified Scrum Trainer and Agile disruptor focused on sustainable value and effectiveness. With a background in product, project, and coaching, Joel blends sharp insights with practical tools to help teams thrive. He is a Miro power user and rocks curated classroom playlists. You can link with Joel Bancroft-Connors on LinkedIn.

5 Kesä 17min

The 90-Day Rule—Building Trust Before Disrupting the Status Quo | Joel Bancroft-Connors

The 90-Day Rule—Building Trust Before Disrupting the Status Quo | Joel Bancroft-Connors

Joel Bancroft-Connors: The 90-Day Rule—Building Trust Before Disrupting the Status Quo 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. Joel shares his first experience as a CSM at a traditional hard drive manufacturing company, where he learned the art of patient change management. Tasked with bridging the gap between a rigid mothership company and their agile startup division, Joel discovered the power of focusing on principles rather than processes. For six months, he concentrated on creating transparency and shifting focus from status reporting to "getting to done" without ever mentioning Scrum or Agile. His approach followed what he calls the 90-day rule: "In the first 90 days - do no harm, but then have a plan to do something." By listening first and building trust, Joel helped the team deliver a product in just three months. He emphasizes the importance of making people feel valued and using "future perfect thinking" to envision desired outcomes before introducing change. In this episode we refer to Luke Hohmann's Innovation Games, the website and resource Manager-Tools.com, and Daniel Pink's book Drive. Self-reflection Question: Are you rushing to implement changes, or are you taking time to build trust and understand the current state before introducing new practices? [Scrum Master Toolbox Podcast Recommends] 🚀 Global Agile Summit 2025 Join us in Tallinn, Estonia, from May 18th – 20th, 2025, for an event that will inspire, challenge, and equip you with real-world Agile success stories. 🌍 Connect with global Agile leaders. 💡 Learn practical strategies for impact. 🔥 Break free from Agile fatigue and become a Pragmatic Innovator Check Full Program [Scrum Master Toolbox Podcast Recommends] About Joel Bancroft-Connors Joel Bancroft-Connors is The Gorilla Coach — a Certified Scrum Trainer and Agile disruptor focused on sustainable value and effectiveness. With a background in product, project, and coaching, Joel blends sharp insights with practical tools to help teams thrive. He is a Miro power user and rocks curated classroom playlists. You can link with Joel Bancroft-Connors on LinkedIn.

4 Kesä 14min

How Performance Reviews Killed a Great Agile Team | Joel Bancroft-Connors

How Performance Reviews Killed a Great Agile Team | Joel Bancroft-Connors

Joel Bancroft-Connors: How Performance Reviews Killed a Great Agile Team 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. Joel tells the story of a team caught in the crossfire of a poorly executed large-scale agile transformation. While the CTO championed going agile, they quickly checked out, leaving the organization without clear direction or understanding of why they were adopting agile practices. The company measured success through output metrics like "number of teams trained" rather than meaningful outcomes. Joel worked with an exceptional team that had built their own collaborative workspace and was performing well, but external forces kept pulling them out of flow. Performance reviews created internal conflict, leading team members to focus on individual success rather than collective achievement. The team ultimately fell into their own traps, with everyone "focusing on themselves and throwing others under the bus." Joel recommends balancing performance evaluations with 50% team-based and 50% individual metrics to prevent this destructive pattern. Self-reflection Question: Does your team truly understand why they are using Scrum, or are they just going through the motions of the framework? Featured Book of the Week: Start with Why by Simon Sinek Joel credits Simon Sinek's "Start with Why" as a transformational influence on his coaching approach. The book's central principle that "people don't buy what you do, they buy why you do it" fundamentally changed how Joel teaches Scrum. He realized he had been teaching Scrum incorrectly by focusing on the mechanics rather than the purpose. Now Joel listens to this book annually and has shifted his focus to helping teams and organizations understand why Scrum matters and why it's important. This shift from teaching the "what" to emphasizing the "why" has made his coaching significantly more effective and meaningful. Joel also mentions the book Coaching Agile Teams by Lyssa Adkins. [Scrum Master Toolbox Podcast Recommends] 🚀 Global Agile Summit 2025 Join us in Tallinn, Estonia, from May 18th – 20th, 2025, for an event that will inspire, challenge, and equip you with real-world Agile success stories. 🌍 Connect with global Agile leaders. 💡 Learn practical strategies for impact. 🔥 Break free from Agile fatigue and become a Pragmatic Innovator Check Full Program [Scrum Master Toolbox Podcast Recommends] About Joel Bancroft-Connors Joel Bancroft-Connors is The Gorilla Coach — a Certified Scrum Trainer and Agile disruptor focused on sustainable value and effectiveness. With a background in product, project, and coaching, Joel blends sharp insights with practical tools to help teams thrive. He is a Miro power user and rocks curated classroom playlists. You can link with Joel Bancroft-Connors on LinkedIn.

3 Kesä 12min

When Great Scrum Masters Fail—The Hidden Cost of Poor Value Communication | Joel Bancroft-Connors

When Great Scrum Masters Fail—The Hidden Cost of Poor Value Communication | Joel Bancroft-Connors

Joel Bancroft-Connors: When Great Scrum Masters Fail—The Hidden Cost of Poor Value Communication 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. Joel shares a powerful lesson about the critical importance of communicating value beyond team performance. Despite achieving remarkable success with multiple teams as an agile coach, Joel and his colleagues ultimately failed because they couldn't effectively demonstrate their value to leadership. The teams were thriving, but when budget cuts came, the coaching support was eliminated first. Without ongoing support, these successful teams began to deteriorate. Joel emphasizes that as Scrum Masters and agile coaches, we must actively communicate our impact and connect team success to business outcomes. Simply assuming that good team performance speaks for itself is not enough - we need to interact more with stakeholders and clearly articulate the value we create. In this episode, we refer to the TV series Ted Lasso, and the books Start with Why by Simon Sinek, and Coaching Agile Teams by Lyssa Adkins. Self-reflection Question: How effectively are you communicating the business value of your Scrum Master activities to leadership, and what specific metrics or stories could better demonstrate your impact? [Scrum Master Toolbox Podcast Recommends] 🚀 Global Agile Summit 2025 Join us in Tallinn, Estonia, from May 18th – 20th, 2025, for an event that will inspire, challenge, and equip you with real-world Agile success stories. 🌍 Connect with global Agile leaders. 💡 Learn practical strategies for impact. 🔥 Break free from Agile fatigue and become a Pragmatic Innovator Check Full Program [Scrum Master Toolbox Podcast Recommends] About Joel Bancroft-Connors Joel Bancroft-Connors is The Gorilla Coach — a Certified Scrum Trainer and Agile disruptor focused on sustainable value and effectiveness. With a background in product, project, and coaching, Joel blends sharp insights with practical tools to help teams thrive. He is a Miro power user and rocks curated classroom playlists. You can link with Joel Bancroft-Connors on LinkedIn.

2 Kesä 15min

BONUS Martti Kuldma: How to Transform Century-Old Organizations Through Product-Driven Agile Transformation

BONUS Martti Kuldma: How to Transform Century-Old Organizations Through Product-Driven Agile Transformation

BONUS: Martti Kuldma shares how to transform century-old organizations through product-driven agile transformation In this BONUS episode we explore the remarkable transformation journey at Omniva with CEO Martti Kuldma. From traditional postal services to innovative logistics solutions, we explore how a 100+ year old company embraced product thinking, DevOps practices, and agile transformation to become a competitive force in modern logistics. Omniva's Digital Evolution—IT as a Revenue Center "We innovated the parcel machine business for a few years, and software has been an area of investment for us - software as a separate vertical in our business." Omniva represents a fascinating case study in organizational transformation. While many know it as Estonia's post office, the company has evolved into an international logistics powerhouse with significant revenue streams beyond traditional postal services. Under Martti's leadership, the organization has reimagined software not as a support function but as a core revenue driver, positioning itself for the dramatic shifts expected in logistics delivery over the next five years. The Vision: Physical Mailing as the Next IP Network "The Vision: physical mailing as the next IP network - this will give us a lot more freedom to adapt to changes in delivery demand." Martti's strategic vision extends far beyond conventional logistics thinking. By conceptualizing physical delivery networks similar to internet protocols, Omniva is preparing for a future where logistics companies leverage their physical infrastructure advantages. This approach addresses the fundamental challenge of fluctuating demand in e-commerce and traditional logistics, creating opportunities for crowd delivery solutions and gig economy integration that capitalize on existing network effects. Breaking Down Waterfall Barriers "When I came we had waterfall processes - annual budgeting, procurement for software development. It took a couple of weeks to do the first rounds, and understand what could be improved." The transformation from traditional procurement-based software development to agile product teams required dismantling entrenched processes. Martti discovered that the contractor model, while seemingly cost-effective, created expensive knowledge transfer cycles and left the organization vulnerable when external teams departed. His engineering background enabled him to recruit talent and build sustainable development capabilities that keep critical knowledge within the organization. Creating Cross-Functional Product Teams "We started to create cross-functional product area teams. We are not going to tell you what you need to build. You are accountable for the logistics efficiency." The shift from eleven distinct roles in software development to autonomous product teams represents more than organizational restructuring. By empowering teams with accountability for business outcomes rather than just deliverables, Omniva transformed how work gets planned and executed. This approach eliminates traditional handoffs and role silos, creating teams that own both the problem and the solution. The Product Manager Evolution "For me, the PM is directly accountable for the business results. The final step of the transformation started when I took the CEO role." Martti identifies a critical challenge in agile transformations: the misunderstanding of Product Manager responsibilities. Rather than falling into delivery or project management patterns, effective PMs at Omniva own business results directly. This shift required company-wide transformation because technical changes alone cannot sustain organizational evolution without corresponding changes in mindset and accountability structures. Leadership Through Storytelling "My main tool is just talking. All I do is story-telling internally and externally. I needed to become the best salesman in the company." The transition from technical leadership to CEO revealed that transformation leadership requires different skills than technical management. Martti discovered that his primary value comes through narrative construction and communication rather than direct technical contribution. This realization highlights how senior leaders must evolve their impact methods as organizations scale and transform. Real-Time Feedback Philosophy "The feedback needs to be given immediately. 'Last year, in May your performance was not the best' - this is completely useless feedback." Martti's rejection of annual reviews stems from practical experience with feedback effectiveness. Immediate, personal feedback creates learning opportunities and course corrections that annual cycles cannot provide. Anonymous 360 feedback systems often dilute accountability and actionability, whereas direct, timely conversations enable meaningful professional development and relationship building. Essential Transformation Practices "You need to tell the story - and convince people that this transformation is essential and needed. You need to trust and let them make their own decisions." Drawing from experiences at both Pipedrive and Omniva, Martti identifies three critical elements for leading complex organizational change: Compelling narrative: People need to understand why transformation is necessary and how it benefits both the organization and their individual growth Distributed decision-making: Trust enables teams to solve problems creatively rather than waiting for hierarchical approval Business accountability for engineers: When technical teams understand and own business outcomes, they innovate more effectively toward meaningful goals The dynamic team formation model used at Pipedrive, where engineers and PMs pitched ideas and assembled mission-focused teams, demonstrates how organizational structure can enable rather than constrain innovation. About Martti Kuldma Martti Kuldma is CEO of Omniva, leading its transformation into a product-driven logistics company. A former engineering leader at Pipedrive and CTO at Omniva, he brings deep expertise in scaling teams, agile transformation, and digital innovation. Martti is also a startup founder and passionate advocate for high-impact product organizations. You can link with Martti Kuldma on LinkedIn.

31 Touko 44min

BONUS Entertainment That Makes Change: Lessons in Product Thinking from Believe Ltd. With Patrick James Lynch

BONUS Entertainment That Makes Change: Lessons in Product Thinking from Believe Ltd. With Patrick James Lynch

BONUS: Patrick James Lynch on Entertainment That Makes Change - Lessons in Product Thinking from Believe Ltd. In this BONUS episode we explore how Patrick James Lynch, filmmaker, media executive, and rare disease advocate, has built Believe Limited around a powerful mission: entertainment that effects change. Patrick shares his journey from personal experience with his brother's hemophilia to creating award-winning content that empowers rare and chronic disease communities, offering valuable lessons for product managers on human-centered design, stakeholder alignment, and building emotionally viable products. The Genesis of Entertainment That Effects Change "This is more than a product." Patrick's journey began with a deeply personal question about his brother who had hemophilia. As an entrepreneur, he set out to respond to an identified need with one product to meet that need, but quickly realized the scope was much larger. His curiosity about what was different between him and his brother led him to understand that he needed to help people like his brother. This realization drove him to create valuable online videos to engage their audience, marking the beginning of Believe Ltd.'s mission of entertainment that effects change. Essential Product Lessons: Listen, Learn, and Do No Harm "The fact that I am my audience, does not mean that I'm an expert." Patrick emphasizes the critical importance of conducting thorough needs assessments and truly understanding your community before building products. Key insights include: Embed yourself in the community you're serving rather than making assumptions Follow the principle of "listen, learn and do no harm" as your starting point Involve community engagement as a dedicated role - Believe Ltd. has a VP of community engagement Define clear phrases that explain the value you deliver to your audience Use your personal story to establish credibility and relate experiences to your audience The goal is to get as familiar with your community as possible, then conduct your own research and development based on those deep insights. Navigating Multi-Stakeholder Complexity "Collaboration only succeeds when all points of view are respected." Working with patients, funders, healthcare professionals, and pharmaceutical companies requires careful orchestration. Patrick's approach centers on prioritizing the end game and identifying the north star goal that aligns all parties. He emphasizes focusing on combined skills and networks rather than trying to accomplish everything at the start. The key is ensuring that aligning stakeholders becomes a central part of the process, with everyone being accounted for throughout the journey. Human-Centered Storytelling as Product Strategy "What's the story that shows the value add of your product?" Patrick advocates for human-centered storytelling as a fundamental product approach. Rather than leading with features or specifications, he suggests crafting stories that demonstrate real value - like how a thermos saved someone's life while hiking. Stories have been humanity's primary communication tool since the beginning of time, and they remain the most effective way to show product value and connect with audiences on a meaningful level. Being a Value Fundamentalist "At any given moment, if anyone takes a screen grab, and set it against our five core values as a company - you see it's playing out." Patrick describes himself as a value fundamentalist, meaning that their company's core values are always present in everything they do. This requires courage, including the willingness to say "no" when opportunities don't align with their values. As CEO, he believes in embodying these values consistently, even when it's challenging, because who they are must always be visible in their work. Balancing Vision with Community Feedback "When you ask the audience for a solution, there's no innovation." Patrick warns against sacrificing vision simply because you're working closely with your audience. While being in the sandbox with your community is essential, maintaining your original vision for entertainment that changes minds is equally important. He recommends having someone you can bounce ideas off to help maintain this balance, and remembers that all great things start small and are inherently iterative. Creating Emotionally Viable Products "We can't develop emotional connection by going through a list of features." Beyond minimum viable products, Patrick focuses on emotional viability - the hook that makes people truly care. Emotional connection cannot be built through feature lists but rather through compelling stories that capture people's imagination. When audiences engage with products outside of direct supervision, storytelling becomes the bridge that helps them discover new uses and applications. This creates a dance between product creators and their audience, leading to better product design. The Currency of Attention "Attention is the only currency - there's great wisdom in that." Patrick recognizes that in today's landscape, capturing and maintaining attention is the fundamental challenge. Since everyone is an audience member at different times, this perspective helps inform both strategy and tactics. Products must compete not just on functionality but on their ability to engage and maintain audience interest over time. As a recommended reading, Patrick suggests that we should read "Save The Cat! The Last Book on Screenwriting You'll Ever Need" to understand how to better tell stories about our products. About Patrick James Lynch Patrick James Lynch is a filmmaker, media executive, and rare disease advocate. CEO of Believe Limited and founder of BloodStream Media, he uses his experience with hemophilia to drive award-winning storytelling, health advocacy, and mission-driven content that inspires and empowers rare and chronic disease communities worldwide. You can link with Patrick James Lynch on LinkedIn and follow Patrick James Lynch's work on his website.

29 Touko 41min

BONUS The Startup CTO's Handbook With Zach Goldberg

BONUS The Startup CTO's Handbook With Zach Goldberg

BONUS: Zach Goldberg shares how to build high-performing engineering teams and master the startup CTO role In this BONUS episode, we dive deep into the world of startup leadership with Zach Goldberg, author of The Startup CTO's Handbook. We explore the critical transition from engineering to leadership, the art of balancing technical debt with startup urgency, and the communication skills that separate great CTOs from the rest. The Genesis of The Startup CTO's Handbook "My original training in software engineering was not enough for being a leader. All the people and leadership skills, I had to learn on my own." Zach's journey to writing The Startup CTO's Handbook began with a stark realization about the gap between technical training and leadership reality. Despite his classical software engineering background, he discovered that the people and leadership skills required for CTO success had to be self-taught. The book emerged from a growing Google Doc of topics and frameworks addressing the leadership and management challenges that CTOs consistently face - from hiring and performance management to making strategic decisions under pressure. Today, we can either buy the digital/print book on Amazon, or read the book on GitHub. In this segment, we also refer to the book The Great CEO Within. Learning to Truly Learn: The Max Mintz Story "Max only cared about my ability to learn - to get curious about something hard. He wanted to help me deal with complexity." Zach opens his book with a deeply personal story about his mentor, Max Mintz, who fundamentally changed his approach to learning during what he calls "the most impactful single coffee" of his life. Over 1.5 years of conversations, Max taught him that true learning isn't about accumulating facts, but about developing curiosity for hard problems and building the capacity to handle complexity. This lesson forms the foundation of effective CTO leadership - the ability to continuously learn and adapt in an ever-changing technical landscape. The Three Critical CTO Mistakes "As a CTO, the most important 3 things: people, people, people. Do the people have the right energy, the right passion? Assemble the right team." Zach identifies consistent patterns in startup CTO failures across his experience. The first and most critical mistake is undervaluing people decisions - failing to prioritize team energy, passion, and the right assembly of talent. The second category involves investment mistakes, particularly the challenge of balancing short-term survival needs with long-term technical goals. In startups, the ROI timespan is exceptionally short, requiring optimization for immediate objectives rather than hypothetical scale. The third mistake is treating technology as religion rather than tools, losing sight of what the business actually needs. Optimizing for Velocity and Developer Experience "You are optimizing for velocity! What are you doing to help developers get their work done? Look at developer experience as a metric." Successful startup CTOs understand that velocity - the time from idea to valuable market delivery - is paramount. This requires a fundamental shift in thinking about technology decisions, focusing on features that deliver real customer value rather than technical elegance. Zach emphasizes measuring developer experience as a key metric, recognizing that anything that helps developers work more effectively directly impacts the company's ability to survive and thrive in competitive markets. The Professional Skill Tree Concept "It's like a character progression in an RPG. When we learn one type of skills, we don't learn other types of skills. We make investments every day and we have a choice on where we learn." Drawing from gaming metaphors, Zach explains how technical professionals often reach Level 100 in engineering skills while remaining Level 1 in management. The skill tree concept highlights that every learning investment is a choice - time spent developing one skill area means less time available for others. For engineers transitioning to leadership, the key is recognizing opportunities to serve as tech leads, where they can begin setting culture and quality standards while still leveraging their technical expertise. Balancing Kaizen with Startup Urgency "Pick the high-impact debt, and pay that down. This is not always easy, especially because we also need to pick what debt we don't invest on." The tension between continuous improvement and startup speed requires sophisticated thinking about technical debt. Using financial analogies, Zach explains that technical debt has both principal and interest components. The key is identifying which debt carries the highest interest rates and can be paid down most quickly, while consciously choosing which debt to carry forward. This approach maintains the healthy tension between quality and speed that defines successful startup engineering. The Power of Audience Empathy "The single hardest skill, especially for very tech leaders is that of 'audience empathy.' When you explain ideas to people, you usually assume a lot - but they might not." According to Zach, the most undervalued communication habit for startup tech leaders is developing audience empathy. Technical leaders often suffer from the curse of knowledge, assuming their audience shares their context and understanding. The solution requires deliberately considering what the audience already knows before crafting any communication, whether it's explaining technical concepts to non-technical stakeholders or providing clear direction to team members. In this segment we refer to the concept of "the curse of knowledge", a cognitive bias that occurs when a person who has specialized knowledge assumes that others share in that knowledge. About Zach Goldberg Zach Goldberg is a seasoned technical entrepreneur, executive coach, and author of The Startup CTO's Handbook. With a founder's mentality and a passion for systems thinking, Zach helps engineering leaders build high-performing teams. He also founded Advance The World, a nonprofit inspiring youth in STEM through immersive experiences. You can link with Zach Goldberg on LinkedIn, and visit Zach's website at CTOHB.com.

28 Touko 41min

Suosittua kategoriassa Politiikka ja uutiset

rss-ootsa-kuullut-tasta
aikalisa
tervo-halme
ootsa-kuullut-tasta-2
politiikan-puskaradio
viisupodi
rss-podme-livebox
et-sa-noin-voi-sanoo-esittaa
otetaan-yhdet
rss-vaalirankkurit-podcast
aihe
the-ulkopolitist
rss-polikulaari-humanisti-vastaa-ja-muut-ts-podcastit
rss-hyvaa-huomenta-bryssel
rss-kuka-mina-olen
politbyroo
linda-maria
rss-lets-talk-about-hair
rss-50100-podcast
rss-tekoalyfoorumi