Culture and Methodologies

As organizations adopt microservices and containerized architectures, they often realize that they need to rethink their approach to basic operational tasks like security or observability. It makes sense: in a world where developers – rather than operations teams – are keeping applications up and running, and where systems are highly distributed, ephemeral, and interconnected, how can you take the same approach you have in the past? From a technology perspective, there has been a clear shift to open source standards, especially in the realm of observability. Protocols like OpenTelemetry and Prometheus, and agents like Fluent Bit, are now the norm – according to the 2023 CNCF survey, Prometheus usage increased to 57% adoption in production workloads, with OpenTelemetry and Fluent both at 32% adoption in production. But open source tools alone can’t help organizations transform their observability practices. As I’ve had the opportunity to work with organizations who have solved the challenge of observability at scale, I’ve seen a few common trends in how these companies operate their observability practices. Let's dig in. Measure Thyself — Set Smart Goals With Service Level Objectives Service Level Objectives were first introduced by the Google SRE book in 2016 with great fanfare. But I’ve found that many organizations don’t truly understand them, and even fewer have implemented them. This is unfortunate because they are secretly one of the best ways to predict failures. SLOs (Service Level Objectives) are specific goals that show how well a service should perform, like aiming for 99.9% uptime. SLIs (Service Level Indicators) are the actual measurements used to see if the SLOs are met — think about tracking the percentage of successful requests. Error budgeting is the process of allowing a certain amount of errors or downtime within the SLOs, which helps teams balance reliability and new features — this ensures they don’t push too hard at the risk of making things unstable. Having SLOs on your key services and using error budgeting allows you to identify impending problems and act on them. One of the most mature organizations that I’ve seen practicing SLOs is Doordash. For them, the steaks are high (pun intended). If they have high SLO burn for a service, that could lead to a merchant not getting a food order on time, right, or at all. Or it could lead to a consumer not getting their meal on time or experiencing errors in the app. Getting started with SLOs doesn’t need to be daunting. My colleague recently wrote up her tips on getting started with SLOs. She advises to keep SLOs practical and achievable, starting with the goals that truly delight customers. Start small by setting an SLO for a key user journey. Collaborate with SREs and business users to define realistic targets. Be flexible and adjust SLOs as your system evolves. Embrace Events — The Only Constant in your Cloud-Native Environment is Change In DevOps, things are always changing. We're constantly shipping new code, turning features on and off, updating our infrastructure, and more. This is great for innovation and agility, but it also introduces change, which opens the door for errors. Plus, the world outside our systems is always shifting too, from what time of day it is to what's happening in the news. All of this can make it hard to keep everything running smoothly. These everyday events that result in changes are the most common causes of issues in production systems. And the challenge is that these changes are initiated by many different types of systems, from feature flag management to CI/CD, cloud infrastructure, security, and more. Interestingly, 67% of organizations don’t have the ability to identify change(s) in their environments that caused performance issues according to the Digital Enterprise Journal. The only way to stay on top of all of these changes is to connect them into a central hub to track them. When people talk about “events” as a fourth type of telemetry, outside of metrics, logs, and traces, this is typically what they mean. One organization I’ve seen do this really well is Dandy Dental. They’ve found that the ability to understand change in their system, and quickly correlate it to the changes in behavior, has made debugging a lot faster for developers. Making a habit of understanding what changed has allowed Dandy to improve their observability effectiveness. Adopt Hypothesis-Driven Troubleshooting — Enable Any Developer to Fix Issues Faster When a developer begins troubleshooting an issue, they start with a hypothesis. Their goal is to quickly prove or disprove that hypothesis. The more context they have about the issue, the faster they can form a good hypothesis to test. If they have multiple hypotheses, they will need to test each one in order of likelihood to determine which one is the culprit. The faster a developer can prove or disprove a hypothesis, the faster they can solve the problem. Developers use observability tools to both form their initial hypotheses and to prove/disprove them. A good observability tool will give the developer the context they need to form a likely hypothesis. A great observability tool will make it as easy as possible for a developer with any level of expertise or familiarity with the service to quickly form a likely hypothesis and test it. Organizations that want to improve their MTTR can start by shrinking the time to create a hypothesis. Tooling that provides the on-call developer with highly contextual alerts that immediately focus them on the relevant information can help shrink this time. The other advantage of explicitly taking a hypothesis-driven troubleshooting approach is concurrency. If the issue is high severity, or has significant complexity, they may need to call in more developers to help them concurrently prove or disprove each hypothesis to speed up troubleshooting time. An AI software company we work with uses hypothesis-driven troubleshooting. I recently heard a story about how they were investigating a high error rate on a service, and used their observability tool to narrow it down to two hypotheses. Within 10 minutes they had proven their first hypothesis to be correct – that the errors were all occurring in a single region that had missed the most recent software deploy. Taking the Next Step If you're committed to taking your observability practice to the next level, these tried-and-true habits can help you take the initial steps forward. All three of these practices are areas that we’re passionate about. If you’ll be at KubeCon and want to discuss this more, please come say hello! This article was shared as part of DZone's media partnership with KubeCon + CloudNativeCon.View the Event

When I was a child, I loved making pancakes with my grandmother. As time went on, I became a web developer, and now, instead of pancakes, I create various web projects with my colleagues. Every time I start a new project, I’m haunted by one question: How can I make this development "tasty" not only for the user but also for my colleagues who will work on it? This is a crucial question because over time, the development team may change, or you might decide to leave the project and hand it over to someone else. The code you create should be clear and engaging for those who join the project later. Moreover, you should avoid a situation where the current developers are dissatisfied with the final product yet have to keep adding new "ingredients" (read: functions) to satisfy the demands of the "restaurant owner." Important note: Before I describe my recipe, I want to point out that methods can vary across different teams and, of course, they depend on their preferences. However, as we know, some people have rather peculiar tastes, so I believe it's essential to reiterate even the simplest truths. Selecting the Ingredients: Choose Your Technology Stack Before you start cooking a dish, you usually check what ingredients you already have. If something is missing, you go to the store or look for alternative ways to acquire them, like venturing out to pick them up in the woods. The web development process is similar: before starting your work on a new project, you need to understand what resources you currently have and what you want to achieve in the end. To prepare for creating your technological masterpiece, it helps to answer a series of questions: What are the functional requirements for the project? What exactly needs to be done?Is anything known about the expected load on your future product?Do you have any ready-made solutions that can be reused?If you’re working in a team: What knowledge and skills does each team member possess?Is the programming language/framework you want to use for development still relevant?How difficult and expensive is it to find developers who specialize in the chosen technologies? Even if you’re working on the project alone, always remember the "bus factor" — the risk associated with losing key personnel. Anything can happen to anyone (even you), so it’s crucial to prepare in advance for any hypothetical issues. No Arbitrary Action: Stick to Coding Standards How about trying oatmeal with onions? It’s hard to believe, but I once had such a dish in Kindergarten. This memory is vividly etched in my mind, and it taught me an important lesson. Coding standards were invented for the same reason as “compatibility standards” of food ingredients. They are supposed to improve code readability and understanding by all developers on the team. We avoid debates about the best way to write code, which constructs to use, and how to structure it. When everyone follows the same rules, the code becomes easier to read, understand, and maintain (also mind that maintenance becomes cheaper this way). But that's not the only reason for having standards: adhering to them helps reduce the number of bugs and errors. For instance, strict rules for using curly braces can prevent situations where an operation is accidentally left out of a condition. Line length restrictions make code more readable, and consistent rules for creating conditions in an if statement help avoid logical errors. Strict rules for data types and type casting in languages with less strict typing also help prevent many runtime errors. Coding standards help reduce dependency on specific developers, which is also good for the developers themselves since they won't be bothered with silly questions during their vacation. In popular programming languages, there are generally accepted coding standards supported by the development team and the community around the language. For example, PEPs (Python Enhancement Proposals) are maintained and managed by the Python developer community under the guidance of the Python Software Foundation (PSF). PSR (PHP Standards Recommendations) is a set of standards developed by PHP-FIG (PHP Framework Interoperability Group) for PHP. Golang has stricter coding standards maintained by the language's developers. However, each development team or company may have its own standards in addition to (or instead of) those supported by the community. There can be many reasons for this; for example, the main codebase might have been written long before any standards were established, making it too costly to rewrite. To maintain uniformity in the codebase, the rules may be adjusted. There are tools for automatically checking standards, known as static code analyzers. These tools generally have a wide range of functionality that can be further expanded and customized. They can also detect errors in the code before it is released to production. Examples of such tools include PHPStan, Psalm, and PHP_CodeSniffer for PHP; Pylint, Flake8, and Mypy for Python; golint and go vet for Golang. There are also tools for automatic code fixing code and bringing it up to existing standards when possible. This means much of this work now should not require as much manual labor and resources as it used to. Keep Ingredients Fresh: Constant Refactoring What happens if you don't keep the code fresh, and how can it lose its freshness? Programming languages and libraries (these are the ingredients) get updated, and with that — old ingredients rot. Establish rules on how you keep the code fresh, use automation tools, and update libraries. This advice may seem obvious, but it's frequently neglected: make sure your project's dependencies and server software are constantly monitored and regularly updated. This is especially important since outdated or insecure code presents an easy target for attackers. Just as with code checking and fixing, you don't have to manually update everything; there are numerous automation tools that can assist. For instance, GitHub’s Dependabot automatically identifies outdated or vulnerable dependencies and proposes updates. It's also vital to automate the renewal of security certificates. Expired certificates can cause significant issues, but automating this process is a straightforward task. For instance, if you're using Let's Encrypt certificates, Certbot can automate their renewal. The same concept applies to server software. For larger projects with multiple servers, tools like Puppet, Salt, Ansible, or Chef can be employed to handle updates. For those working with Linux, especially Debian/Ubuntu-based systems, Unattended Upgrades can efficiently manage this. Taste (And Test) Along the Way A good chef usually tastes the dish at different preparation stages to ensure everything is going according to plan. In a similar fashion, a professional developer should check not just the final, but also the intermediate results using tests. Testing is often associated with just detecting bugs. Indeed, it catches errors and unexpected behaviors before the product reaches users, improving overall quality and reducing the likelihood of issues down the line. But in fact, its importance is much bigger than that. Effective testing is crucial for delivering high-quality, dependable, and well-understood code: Code comprehension: Writing test scenarios demands a deep understanding of the code’s architecture and functionality, leading to better insights into how the program operates and how different parts interact.Supplemental documentation: Tests can also serve as practical examples of how functions and methods are used, helping to document the project’s capabilities and providing new team members with real-world use cases. It’s pretty much clear that achieving 100% test coverage for complex code is unrealistic. Therefore, developers must focus on testing critical functions and essential code segments, and knowing when to stop is key to avoiding an endless cycle of testing. Also, testing can consume significant resources, especially during the early stages of development. So, it’s important to strike a balance between the necessity of testing and the available time and resources. Chef’s Logbook: Add a Pinch of Documentation It’s common knowledge that many famous types of food, like mozzarella, nachos, and even french fries, were discovered by accident. Others took decades to develop through countless trial and error. In both cases, all of them would be just one-off products if knowledge about them could not have been passed on. It is the same with tech: each project needs proper documentation. The lack of such paperwork makes it much harder to identify and fix errors, complicates maintenance and updates, and slows down the onboarding process for new team members. While teams lacking documentation get bogged down in repetitive tasks, projects with well-structured documentation demonstrate higher efficiency and reliability. According to the 2023 Stack Overflow Developer Survey, 90.36% of respondents rely on technical documentation to understand the functionality of technologies. Yet, even with documentation, they often struggle to find the information they need, turning to other resources like Stack Overflow (82.56%) and blogs (76.69%). Research by Microsoft shows that developers spend an average of 1-2% of their day (8-10 minutes) on documentation, and 10.3% report that outdated documentation forces them to waste time searching for answers. The importance of documentation is also a significant concern for the academic community, as evidenced by the millions of scientific publications on the topic. Researchers from HAN University of Applied Sciences and the University of Groningen in the Netherlands identified several common issues with technical documentation: Developer productivity is measured solely by the amount of working software.Documentation is seen as wasteful if it doesn’t immediately contribute to the end product.Informal documentation, often used by developers, is difficult to understand.Developers often maintain a short-term focus, especially in continuous development environments.Documentation is frequently out of sync with the actual software. These “practices” should be avoided at all costs in any project, but it is not always up to developers. Getting rid of these bad habits often involves changes to planning, management, and long-term vision of the entire company from top management to junior dev staff. Conclusion As you see, food and tech project development (including, but not limited to web) has a lot in common with cooking. Proper recipes, fresh and carefully selected ingredients, meticulous compliance with standards, and checking intermediate and final results — sticking to this checklist is equally essential for a chef and for a developer. And, of course, they both should ideally have a strong vision, passion for what they do, and a strong appetite for innovation. I am sure you recognize yourself in this description. Happy cooking!

TL;DR: The Perils of Founder Mode This article delves into the darker aspects of Founder Mode, popularized by Paul Graham and others. It offers a critical perspective for agile practitioners, product leaders, startup founders, and managers who embrace this paradigm and probably fall victim to survivorship bias; the Jobs and the Cheskys are the exception, not the rule. The article explores how resulting tendencies, such as micromanagement, lack of strategic transparency, team devaluation, and reckless risk-taking, can undermine organizational health, stifle innovation, and conflict with agile principles. These can jeopardize long-term success while making work in organizations with a failed founder mode application miserable for everyone below the immediate leadership level and the founder himself. The Collateral Damage Caused by Founder Mode The Founder Mode concept suggests that founders should immerse themselves deeply in all facets of their organization, believing their direct involvement is essential for success. While this approach can bring about swift decision-making and maintain a strong vision, it also harbors several hidden pitfalls. These include tendencies toward: Survivorship Bias and the Myth of the Exceptional FounderConfirmation Bias and the Reinforcement of Echo ChambersMisaligned Investor Incentives and the Big Bet MentalityMicromanagementObscured strategic objectivesTaylorism Revisited: Viewing Teams as Replaceable CogsErosion of employee agencyNormalization of reckless risk-takingPrioritization of short-term gains over sustainable cultureIncompatibility with Agile Self-Management Principles Moreover, cognitive biases and misaligned investor incentives can exacerbate these issues: Survivorship Bias and the Myth of the Exceptional Founder The glorification of successful founders contributes to survivorship bias — the logical error of focusing on those who succeeded while overlooking those who did not. Celebrated figures who adopted Founder Mode are often exceptions rather than the rule. Their success stories create a narrative that this approach is universally practical, which is misleading. By emulating these outliers without acknowledging the unique circumstances that contributed to their success, other founders may adopt strategies unlikely to yield the same results. This perpetuates unrealistic expectations and disregards the importance of context in leadership effectiveness. Founder Mode: Confirmation Bias and the Reinforcement of Echo Chambers Founders deeply invested in their ideas are susceptible to confirmation bias — the tendency to search for, interpret, and recall information that confirms preexisting beliefs. This bias is amplified in Founder Mode as dissenting voices are often suppressed or removed, and supportive feedback is amplified. This creates an echo chamber where critical evaluation is lacking, but everyone tells the emperor what the emperor wants to hear. Without diverse perspectives, the organization becomes blind to potential flaws in its strategies, making it vulnerable to preventable mistakes. Misaligned Investor Incentives and the Big Bet Mentality Investors, particularly venture capitalists, may encourage Founder-Mode behaviors by prioritizing rapid growth and significant returns on investment. This “big bet” mentality values aggressive scaling and market domination, sometimes disregarding the negative consequences for organizational health and ethical standards; think Travis Kalanick or Elon Musk. Such misaligned incentives pressure founders to make bold moves without fully considering the risks or collateral damage. This can lead to decisions that harm the company’s long-term prospects in favor of short-term financial gains. Micromanagement Under the Guise of Engagement One of the most significant concerns with Founder Mode is the propensity for micromanagement. Driven by passion and a desire for perfection, founders may involve themselves excessively in day-to-day operations. This over-involvement can lead to a work environment where co-workers feel their expertise is undervalued. The constant oversight impedes their ability to exercise professional judgment, fostering a culture of dependency rather than empowerment. Micromanagement not only stifles creativity but also hampers efficiency. Teams spend valuable time seeking approvals for minor decisions, slowing down processes that “Agile” aims to streamline and accelerate. This contradicts the principles of self-managing teams, which are central to agile practices and are crucial for rapid adaptation in fast-paced markets. Obscured Strategic Goals and the Neglect of Commander’s Intent Clarity of purpose is paramount in complex and uncertain environments. Founder Mode often results in the obfuscation of strategic goals, with founders keeping their overarching plans opaque to maintain control. This lack of transparency prevents teams from understanding the broader context of their work, inhibiting their ability to make informed decisions that align with the company’s vision. The military concepts of “Auftragstaktik” and “commander’s intent” emphasize the importance of conveying the desired end state without dictating the exact means of achieving it. By ignoring these principles, Founder Mode diminishes the effectiveness of teams, as they cannot adapt their strategies in response to changing circumstances without a clear understanding of the ultimate objectives. Taylorism Revisited: Viewing Teams as Replaceable Cogs Founder Mode can inadvertently revive the outdated management philosophy of Taylorism, where workers are seen as interchangeable parts in a machine. This perspective reduces highly skilled professionals to mere executors of the founder’s directives, disregarding their potential contributions to innovation and problem-solving. Such an approach undermines team morale and engagement. Employees’ motivation wanes when they perceive their unique skills and insights as neither recognized nor valued. This affects individual performance and cascades on team dynamics and overall organizational effectiveness. It defies lessons learned on motivation, particularly in knowledge work — see Pink’s 2011 book “Drive: The Surprising Truth About What Motivates Us" — and results in employing financial reward schemes. Erosion of Employee Agency and Autonomy A hallmark of effective modern leadership is empowering employees to make decisions within defined boundaries. Founder Mode, however, often entails a top-down command structure where directives are issued without room for discussion or input. This diminishes employees’ sense of agency, leading to disengagement and a lack of ownership over their work. The suppression of autonomy is particularly detrimental in agile environments, where unpredictability requires responsiveness and adaptability. Teams that lack the authority to adjust their course of action in response to new information cannot effectively navigate the complexities of product development. Normalization of Reckless Risk-Taking Founder Mode can foster a culture where taking significant risks without adequate analysis becomes normalized. The founder’s confidence in their vision may lead them to make high-stakes decisions that jeopardize the company’s future. While bold moves can yield substantial rewards, they can also result in catastrophic failures. This “gambling” mentality, while in line with many venture capitalists’ return on investment expectations, overlooks the importance of calculated risk management. It places the company’s fate on the shoulders of singular, potentially impulsive choices rather than on a balanced strategy that weighs potential gains against possible losses. Prioritization of Immediate Results Over Sustainable Culture Another characteristic of the founder mode is an intense focus on achieving immediate results. While short-term successes can be gratifying, they may come at the expense of building a sustainable organizational culture. Practices that prioritize “getting things done at all costs” often lead to employee burnout, ethical oversights, hero worship, and a toxic work environment. A sustainable culture is vital for long-term success. It attracts and retains top talent, fosters innovation, and builds a strong brand reputation. Neglecting this aspect can have lasting negative impacts that outweigh any short-lived achievements. Incompatibility With Agile Self-Management Principles Agile practices emphasize collaboration, self-organization, and adaptability. Founder Mode’s control-oriented approach is inherently at odds with these principles. Micromanagement and lack of transparency hinder teams’ ability to respond swiftly to changes, collaborate effectively, and take initiative. The success of agile practices relies on trusting teams to manage their work and make decisions that best serve the project’s goals. Founder Mode undermines this trust, leading to rigid processes that stifle innovation and slow down progress. Founder Mode and the Necessity of Agility in a Product Operating Model In a fiercely competitive market, agility is not just beneficial but essential. Therefore, applying a product operating model must be flexible to accommodate shifting customer needs, technological advancements, and competitive pressures. Founder Mode’s centralized decision-making structure impedes this flexibility. Organizations that bottleneck decisions through the founder become less responsive to external changes. This can result in missed opportunities, decreased customer satisfaction, and an inability to stay ahead of competitors. Additional Considerations on Founder Mode While the article covers the key pitfalls associated with the Founder Mode management style, there are a few additional points that might be valuable: The importance of emotional intelligence: Developing emotional intelligence is crucial for leaders who wish to move beyond the limitations of Founder Mode. Leaders can foster a more collaborative and supportive work environment by being attuned to their teams’ emotions and motivations. This enhances team cohesion and encourages open communication, essential for innovation and problem-solving.Navigating organizational growth: As startups evolve into larger organizations, the leadership approach must adapt accordingly. Founder Mode may have been effective in the early stages due to the necessity for rapid decision-making and a clear vision. However, shifting towards more distributed leadership as the company grows can help manage increased complexity and promote scalability.Balancing vision with flexibility: While having a strong vision is essential, rigidity can be detrimental. Leaders should remain open to feedback and be willing to adjust their strategies in response to new information or changing market conditions. This flexibility allows the organization to stay competitive and responsive to external shifts.Cultivating a learning and failure culture: Encouraging continuous learning and development within the organization can counteract some of the negative effects of Founder Mode. By promoting a culture where experimentation is welcomed, and failures are seen as learning opportunities, teams are more likely to innovate and adapt.Ethical leadership and corporate responsibility: Leaders should also consider the ethical implications of their management style. Prioritizing ethical decision-making and corporate social responsibility can enhance the company’s reputation and build trust with stakeholders, including customers, employees, and investors.Alignment with stakeholders: Ensuring that the interests of all stakeholders are considered can help mitigate the misaligned incentives that sometimes arise with aggressive growth strategies. Open dialogue with investors, for instance, can lead to more sustainable expectations and reduce the pressure contributing to risky decision-making. Food for Thought As you reflect on the complexities and potential drawbacks of Founder Mode, consider the following questions to deepen your understanding and explore alternative approaches: Balancing vision and collaboration: How can founders maintain a strong, clear vision while also empowering their teams to contribute ideas and make decisions?Adaptive leadership: How might leaders need to adapt their management style as the organization grows and evolves? How can they recognize when a shift is necessary?Empowering teams: What practical steps can be taken to increase employee agency and autonomy without sacrificing alignment with the company’s strategic goals?Risk management: How can organizations encourage innovative thinking and calculated risk-taking while avoiding reckless or unethical decisions?Cultivating transparency: What mechanisms can be implemented to communicate strategic goals effectively throughout the organization?Mitigating cognitive biases: What strategies can leaders employ to identify and counteract confirmation bias within themselves and their teams?Investor relations: How can founders align investor expectations with sustainable business practices prioritizing long-term success over short-term gains?Learning from failure: Considering the influence of survivorship bias, how can organizations learn from both the successes and failures of others to inform their own strategies?Integrating Agile principles: What adjustments are necessary to reconcile the control-oriented tendencies of Founder Mode with the self-management and adaptability inherent in agile practices?Building sustainable culture: How can focusing on immediate results be balanced with the need to develop a healthy, sustainable organizational culture?Future leadership models: How might alternative leadership models combine founders’ passion and vision with the collaborative and adaptive practices needed in today’s complex business environment? Conclusion While compelling, the myth of the omnipotent founder often masks the underlying dysfunctions that "Founder Mode" leadership can introduce into an organization. This approach runs counter to the very principles that underpin agile practices. Organizations risk eroding the foundation of innovation and adaptability essential in a complex and unpredictable business environment by treating teams as mere executors of a singular vision and stifling their autonomy. Moreover, the normalization of reckless risk-taking and the influence of cognitive biases, such as confirmation bias and survivorship bias, further compound these issues. When combined with misaligned investor incentives that prioritize short-term gains over sustainable growth, the organization becomes vulnerable to strategic missteps that can jeopardize its long-term viability. It is imperative for agile practitioners, product leaders, startup founders, and managers to assess the adoption of "Founder Mode" leadership critically. Embracing a leadership style that values transparency, empowers teams, and promotes responsible risk management is not just preferable but essential. By fostering a culture of collaboration and continuous improvement, organizations can leverage the collective expertise of their teams, enhance their agility, and create sustainable value. By moving beyond the allure of "Founder Mode," organizations position themselves to navigate the market’s uncertainties more effectively. By aligning leadership practices with agile principles, they improve internal dynamics and strengthen their capacity to respond to external challenges. Ultimately, organizations can achieve enduring success and resilience through this deliberate shift towards empowerment and agility. Of course, these considerations take a backseat once an organization identifies its Steve Jobs. However, that is a very, very rare occasion. As Richard P. Feynman said: “The first principle is that you must not fool yourself, and you are the easiest person to fool.” (Source) What is your experience with the Founder Mode model? Please share with us in the comments. Recommended Reading Paul Graham: Founder Mode

By Stefan Wolpers CORE

In software engineering, the role of a “Glue” is vital yet often overlooked. This term refers to the person who connects various teams, ensuring that a complex project with many moving parts comes together seamlessly. If you’re leading a zero-to-one software project that spans more than a couple of teams, your role as the Glue becomes even more critical. This article explores strategies for managing team dependencies, scheduling demos, building alignments, and adapting to pivots while maintaining focus on user needs. 1. Managing Team Dependencies When working across multiple teams, managing dependencies is one of the biggest challenges. Each team might have its own goals, timelines, and constraints, which can create friction if not carefully coordinated. Here’s how to effectively manage these dependencies: Dependency Mapping Start by creating a detailed dependency map. This involves identifying all the critical interdependencies between teams. For example, if the backend team needs certain APIs ready before the frontend team can implement features, this should be clearly documented and tracked. Regular Syncs Implement regular cross-team sync meetings where representatives from each team come together to discuss progress, roadblocks, and upcoming needs. These meetings should be concise but comprehensive, ensuring everyone is on the same page. Shared Documentation Utilize shared documentation tools like Confluence or Notion to maintain a living document that outlines dependencies, timelines, and responsibilities. This document should be easily accessible and regularly updated to reflect the current state of the project. Use of Project Management Tools Leverage project management tools like Jira or Asana to track tasks, assign ownership, and monitor progress. These tools can help visualize dependencies, making it easier to identify potential bottlenecks before they become critical issues. 2. Scheduling Demos Demos are a crucial part of any zero-to-one project, as they allow teams to showcase their progress, gather feedback, and align with the overall project goals. Here’s how to schedule and manage demos effectively: Regular Cadence Establish a regular cadence for demos, such as bi-weekly or monthly sessions. This consistency helps keep teams accountable and ensures continuous progress. Cross-Team Involvement Encourage cross-team involvement in demos. Even if a particular team isn’t directly involved in the feature being demoed, their input can provide valuable perspectives and help identify unforeseen dependencies. Targeted Feedback Sessions After each demo, hold targeted feedback sessions where the relevant teams can discuss the demoed features in detail. This allows for immediate course corrections and ensures that all feedback is considered before moving forward. User Involvement If possible, involve end-users in demos, especially in the later stages of development. This direct feedback can be invaluable in refining features and ensuring that the final product meets user needs. 3. Building Alignment Across Teams Alignment is essential when working with multiple teams on a single project. Misalignment can lead to wasted effort, missed deadlines, and ultimately, a product that doesn’t meet expectations. Here’s how to build and maintain alignment: Unified Vision Start by ensuring that all teams understand and buy into the project’s vision. This can be achieved through an initial kickoff meeting where the project’s goals, objectives, and success metrics are clearly defined and communicated. Communication Channels Set up clear and efficient communication channels. Whether through Slack, Microsoft Teams, or regular video calls, ensuring that everyone has a direct line of communication is critical to maintaining alignment. Role Clarity Clearly define the roles and responsibilities of each team. This includes specifying what each team is responsible for, how they will be measured, and how their work contributes to the overall project. This clarity helps prevent overlap and ensures that all aspects of the project are covered. Alignment Workshops Hold regular alignment workshops where teams can discuss their progress, share challenges, and adjust their strategies. These workshops should be collaborative, with the goal of ensuring that all teams are moving in the same direction. 4. Pivoting and Working With Users In any zero-to-one project, there will be times when you need to pivot based on new information, user feedback, or changing business priorities. Here’s how to manage pivots and maintain a user-centered approach: User-Centered Design From the outset, make user needs central to your design and development process. Conduct user research, create personas, and map user journeys to ensure that the product you’re building truly solves the problems it’s intended to. Iterative Development Adopt an iterative development approach, such as Agile, where you can quickly adapt to changes and incorporate user feedback. This flexibility is crucial when you need to pivot, as it allows you to change course without derailing the entire project. Early and Frequent User Testing Involve users early and often in the testing process. This can include usability testing, A/B testing, and beta releases. The insights gained from these tests can inform whether a pivot is necessary and how it should be executed. Scenario Planning Prepare for pivots by engaging in scenario planning. This involves considering various “what if” scenarios and developing contingency plans. By doing this, you can pivot more smoothly and with less disruption when the need arises. Stakeholder Management Keep all stakeholders informed about potential pivots and the rationale behind them. This transparency helps maintain trust and ensures that everyone is aligned with the new direction. Conclusion Being the Glue in a zero-to-one software project that spans multiple teams is a challenging yet rewarding role. By effectively managing team dependencies, scheduling impactful demos, building strong alignment, and being prepared to pivot based on user feedback, you can help steer the project to a successful launch. The key is to maintain clear communication, foster collaboration, and stay focused on the end goal — delivering a product that not only meets business objectives but also delights users.

Agile transformations can be tough. They’re messy, time-consuming, and more often than not, they fail to deliver the promises that got everyone excited in the first place. That’s why it’s so important to approach an Agile transformation as a full-scale organizational change rather than just a shift in how our development teams work. In my years as a change management consultant, I have studied and applied various change management models, from John Kotter’s 8-Step Change Model to ADKAR and Lean Change Management by Jason Little. I have learned through these experiences and countless transformations that there isn’t a one-size-fits-all approach. That’s why I have developed the VICTORY framework. It’s a straightforward approach, blending the best practices from multiple models with practical insights from leading Agile transformations at scale. The idea is to make it easy to remember and apply, no matter the size or complexity of the organization. The VICTORY Framework for Transformation The VICTORY framework is designed to guide organizations through the often chaotic and challenging process of organizational transformation — not just Agile Transformation. Following this framework ensures the change is not just strategic but sustainable. Here’s how it works: V: Validate the Need for Change Every transformation has to start with a strong reason. Before diving into the change, it’s crucial to validate why the transformation is necessary. What are the core issues driving this change? What happens if we don’t make these changes? We need to establish a sense of urgency to get everyone aligned and committed. Without a compelling “Why,” it’s tough to get the buy-in needed for a successful transformation. Steps To Take Analyze the current challenges and pain points.Engage with key stakeholders to understand their perspectives.Clearly communicate the risks of staying the course without change. I: Initiate Leadership Support Strong leadership is the backbone of any successful transformation. We start by securing solid support from executive leaders and finding champions within the organization who can help drive the change. These leaders will be our advocates, offering feedback and refining the transformation goals as we go along. Steps To Take Get top executives on board and invest in the change.Identify and empower champions across different levels of the organization.Set up channels for continuous communication and feedback. C: Craft a Clear Vision A transformation without a clear vision is like setting off on a journey without a map. We need a vision that is motivating, realistic, and capable of bringing everyone together. This vision should clearly explain why the change is necessary and what the organization will look like once the transformation is complete. It’s also important to test this vision with small groups to make sure it resonates with people at all levels. Steps To Take Develop a vision statement that aligns with the organization’s overall goals.Communicate this vision consistently across the organization.Gather feedback to ensure the vision is clear and inspiring. T: Target Goals and Outcomes With our vision in place, it’s time to get specific about what we want to achieve. We define clear, measurable goals and outcomes. Establishing metrics is crucial — these will keep us on track and provide a way to measure success. This is also the stage where we’ll need to create or adapt tools that will help us track progress effectively. Steps To Take Set specific, achievable goals aligned with the vision.Define key objectives and results to monitor progress.Review and adjust goals regularly as the transformation unfolds. O: Onboard With Pilot Teams Instead of launching the transformation organization-wide from the get-go, we start with pilot teams. These teams will help us test new structures, roles, tools, and processes. It’s essential to provide them with the necessary training and support to set them up for success. The insights we gain from these pilots will be invaluable in identifying potential challenges and making adjustments before scaling up. Steps To Take Choose pilot teams that represent a cross-section of the organization.Provide tailored training and ongoing support.Monitor the pilot phase closely to gather insights. R: Review and Adapt Continuous improvement is at the heart of Agile, and that applies to our transformation process, too. We regularly review how the pilot teams are progressing, gather feedback, and measure outcomes. This approach allows us to learn from early experiences and make necessary adjustments before the transformation goes organization-wide. Steps To Take Hold regular retrospectives with pilot teams to gather insights.Adjust the transformation strategy based on what’s working (and what’s not).Share learnings across the organization to keep everyone informed and engaged. Y: Yield To Continuous Scaling Once our pilots are running smoothly, it’s time to scale the transformation across the organization — but do it gradually. Expanding in phases allows us to manage the change more effectively. During this phase, we ensure that governance structures, roles, and performance metrics evolve alongside the new ways of working. Keeping leadership engaged is critical to removing obstacles and celebrating wins as we go. Steps To Take Plan a phased rollout of the transformation.Align governance structures with the new processes.Maintain executive engagement and celebrate every milestone. Don’t Forget the Individual Impact As our organization undergoes this transformation, it’s crucial not to overlook the individuals who will be affected by these changes. This means understanding how the transformation will impact roles, responsibilities, and workflows at a personal level. Each person should feel that they have something positive to look forward to, whether it’s new opportunities for growth, skill development, or simply a more satisfying job. Steps To Take Assess how each role will be impacted by the transformation.Align individual roles with the new ways of working, making sure everyone understands the benefits.Offer opportunities for growth and development that align with the transformation’s goals. Wrapping It Up The VICTORY framework provides a structured yet flexible approach to transformation. By validating the need for change, securing leadership support, crafting a clear vision, targeting specific goals, onboarding with pilot teams, continuously reviewing and adapting, and scaling the transformation gradually, we can navigate the complexities of any kind of transformation effectively. Moreover, focusing on the individual impact of the transformation ensures that the change is not just successful at the organizational level but also embraced by the people who make up the organization. This framework offers a practical roadmap for organizations looking to become more Agile and adaptive in today’s rapidly changing business environment. By following the VICTORY framework, we can increase our chances of a successful, sustainable transformation that benefits both the organization and the individuals within it.

Sometimes in our careers, we feel like we're not progressing from our current level. Well, who doesn't? The least said about it, it is an annoying place to be: working hard, putting in long hours, and feeling like our career is going nowhere. I was there too. So, after having navigated my way through it, here's advice I wish I could give my past self. The Reality Check: Why Hard Work Alone Isn’t Enough I’ve noticed a common myth at workplaces that working long hours will get you a promotion. The reality is that putting in extra hours is not a differentiator. While dedication and a strong work ethic are important, it may not take you to the next level. Any leadership looks for people who can tackle higher-level challenges and lead through influence rather than effort. You have more chances to move forward if you are a strategic thinker rather than a hard worker. A lot of successful experts who have climbed the ladder have a few things in common: they prioritize strategic impact, lead by example, and take the initiative to tackle further complex challenges. Camille Fournier, former CTO of Rent the Runway, emphasizes in her book "The Manager's Path" that transitioning from an individual contributor to a leadership role requires a focus on guiding others and taking on projects that impact the entire organization. Think about the following engineers. The first engineer regularly completes work by working after hours, produces a lot of code, and meets deadlines. In contrast, the second one assumes responsibility for cross-functional projects, focuses on identifying trends, solving issues that affect numerous teams, and shares knowledge to elevate team productivity. Although both engineers are valuable, the second engineer has a much higher chance of being given a promotion. Why? He is not only making a positive contribution to the team but also driving its success and exhibiting crucial leadership traits at the senior level. The Path to Promotion: Focus on Next-Level Problems and Leadership To get past mid-senior you need to stop focusing on the work you do and focus on the impact of that work. Will Larson, in his book, "An Elegant Puzzle," discusses how senior engineers should focus on high-leverage activities, such as system design and mentorship, rather than getting caught up in day-to-day coding tasks. Below are three-step strategies that can help you grow. 1. Work on Next-Level Scoped Problems At the mid-senior level, technical skills are expected. What distinguishes you is your ability to work on problems of a larger scope and greater strategic importance. These are problems that require not only technical expertise but also business acumen and the ability to connect your solutions to the company's long-term goals. Here is an example of owning a cross-team initiative. Suppose there are problems integrating a certain new technology stack across different products. Instead of contributing to this initiative by writing code for only your application, one could take ownership of the entire project. This would be carried out by coordinating with the involved teams, understanding the variations in need and constraint, and thereafter delivering a solution keeping in view the overall strategy of the product platform. This means you're solving more than a problem: you can show that you can manage complexity, influence others, and drive outcomes that have a material impact on the business. 2. Deliver Through Others As you go up the career ladder, success for you will be delivered through influencing and guiding people around you. This perhaps will be one of the most important transitions from an individual contributor to a leader. Whether you mentor, delegate, and collaborate across teams is going to be most crucial for your promotion. Suppose you are tasked with the implementation of some new feature. Instead of making the whole implementation yourself, you realize that there's a junior who can take on some portions of the implementation. You then invest in teaching them through proper specification and best practices needed. By effectively delegating, you empower others, freeing your time for more strategic activities at higher levels. This way, you show that you can lead a team, which is one of the competencies needed to access senior positions. 3. Think Strategically and Be Proactive The level at which you work requires good execution; you must think strategically. That means knowing the context of the business, knowing what problems are going to happen in the future, and therefore proactively suggesting solutions. Suppose you find your company's development process hemorrhaging inefficiencies, slowing down the release cycle. Maybe instead of waiting for another person to fix that problem, you could propose a new initiative that smooths out the process. You would research best practices, build stakeholder support, and lead the implementation of the new process. This proves that apart from you being a problem solver, you are also a strategic thinker who can seize opportunities and ensure change. Final Words: Shift Your Mindset, Elevate Your Career If you feel stuck at your current level, it’s time to rethink your approach. Growing is not just about working harder — they’re about demonstrating your ability to handle next-level challenges and lead others to success. Jeff Shannon, author of "Hard Work is Not Enough: The Surprising Truth about Being Believable at Work," wrote that people will tell you that hard work will take you far, but it won't. He believes that "hard work is a good start" to get yourself established early in your job, but it is not enough to help you rise to the top. Start by focusing on problems that have a broader impact, mentor and guide your peers, and think strategically about how you can contribute to the company’s long-term goals. By making these shifts, you’ll not only position yourself for progression but also develop the skills and mindset needed to thrive in senior-level roles. It isn’t just about the hours you put in—it’s about the difference you make.

By Gaurav Gaur CORE

The Night That Changed Everything Remember the days when your phone buzzed more often than a beehive in spring? That was us, drowning in a sea of alerts. Our Slack channels looked like Times Square on New Year's Eve, and our PagerDuty . . . well, let's just say it was living up to its name a little too enthusiastically. We were facing a classic case of alert fatigue, and it wasn't just costing us sleep — it was impacting our ability to respond to real incidents. Something had to give, and it wasn't going to be our sanity. The Reality We Were Facing Looking back, it's almost funny how bad things had gotten. Almost. We had alerts for everything. And I mean everything. Server hiccup? Alert. Tiny traffic spike? Alert. Someone breathe on the database? You guessed it, alert.Finding a real problem was like searching for a needle in a haystack. A very loud, annoying haystack.Our alerts were everywhere. Slack, email, PagerDuty — you name it, we had alerts there. It was chaos. How We Turned Things Around The next morning, running on more coffee than sleep, I called a team meeting. We knew we had to change things, but where to start? Here's what we came up with: 1. Operation: Slack Cleanup First things first, we had to get our Slack under control. We created one channel — just one — for all our important alerts. It was like finally organizing that junk drawer in your kitchen. Suddenly, we could see what we were dealing with. 2. The Dashboard Dream One of our newer team members had been tinkering with Datadog. We gave him the green light to go all out. A week later, he came back with a dashboard that blew us away. For the first time, we could see our entire system at a glance. It was like going from a flip phone to a smartphone. 3. Weekly Alert Therapy We started meeting every Friday to go over the week's alerts. It was part post-mortem, part planning session, and, let's be honest, part group therapy. But it worked. We started seeing patterns we'd never noticed before. 4. Taming the Noisiest Alerts Instead of trying to fix everything at once, we focused on the worst offenders. Each week, we'd pick the 2-3 alerts that were driving us the craziest and work on those. Slow progress, but progress nonetheless. 5. Rewriting the Rulebook We took a hard look at our alert rules. Some of them were older than our newest team members. We updated, rewrote, and sometimes just flat-out deleted rules that weren't serving us anymore. 6. Monthly Alert Audit Once a month, we'd take a step back and look at the big picture. Were our changes working? What new problems were cropping up? It was like a monthly health check for our alert system. The Results (Or, How We Got Our Lives Back) I won't lie, it took time. But after a few months, the difference was night and day: Our alert volume dropped by almost half. Suddenly, when an alert came in, we knew it mattered.People started looking. . . rested? The bags under our eyes were disappearing, and our caffeine budget went down.Most importantly, we were catching real issues faster than ever. Turns out that when you're not drowning in noise, it's easier to hear the important stuff. What We Learned This whole experience taught us a lot. Maybe the biggest lesson was that alerts are supposed to help us, not run our lives. We learned to be picky about what deserves our immediate attention and what can wait. Going forward, we're sticking to a few key principles: We review our alerts regularly. What made sense six months ago might not make sense now.We're always looking for ways to make our system smarter. Better tools, better processes — whatever helps us work smarter, not harder.We talk. A lot. About what's working, what's not, and how we can do better. The Bottom Line Look, our system isn't perfect. We still get woken up sometimes, and we still have the occasional false alarm. But it's so much better than it was. We're not just reacting anymore; we're in control. To any team out there drowning in alerts: there's hope. It takes work, and yeah, probably a few late nights. But trust me, when you get to silence your phone at night and actually sleep? It's worth it. Here's to fewer alerts, more sleep, and happier engineers. We got there, and you can too. Additional Contributor This article was co-authored by Seema Phalke.

In the world of software engineering, a conflict between a product manager's vision and the engineering team's technical strategy is a recurring obstacle for many teams. While product managers strive to create disruptive and innovative products, engineers need to ensure that these visions can be implemented into successful realities either within the constraints of current technology or discover a breakthrough themselves. The gap between the product vision and the technical realities can be a daunting challenge, but balancing these two aspects is crucial for the success of any project. This article explores the dynamics between product vision and technical reality and how taking an iterative approach can help navigate the gap between the aspect and the feasibility. Understanding the Product Vision Imagine you are a builder (software developer) and are hired by a family (product manager) to build a house. The family will have an image of a dream house in their mind — a beautiful, large, comfortable home that will fulfill all their functional and lifestyle dreams (vision). Now, for the builder to do their job well, they need to understand the family's vision and then build upon it. But at the same time, the family's vision also needs to be well crafted and decipherable for the builder to comprehend it. Along similar lines, a well-defined and well-constructed product vision is essential for guiding a successful technical strategy. At the same time, it is equally essential to ensure that this vision maps to a feasible reality. The engineering team should actively participate in shaping the product vision, adding insights about technical constraints or potential limitations. Even if the product vision is deemed ambitious or poses technical challenges, there is always a product strategy guiding that vision. Product managers and the engineering team should meet regularly to whiteboard and plan solutions, ensuring a technically viable plan is driving this strategy. This way, the engineering team can build and apply the technical strategy at a micro level and make better decisions for execution. What Happens When the Product Strategy Doesn’t Align With the Technical Strategy? While collaborative meetings or whiteboarding sessions are a necessity, there are two other key areas where forgoing can quickly create grounds for failure: Roadmap and Ownership. If the product and engineering organizations are not in alignment about what features they want to build and when or if they do not have clear ownership metrics about who will drive the planning and execution decisions, it can quickly lead to an array of problems. Launch delays, resourcing constraints, organizational friction, and increased costs are some of the most common ones. Contrary to the above, when engineers start getting pulled into more strategic discussions to brainstorm questions like what should we build along with the "how to" and "can we" build it, sometimes overreliance on execution strategy (the how?) can also hamper "the what" and "the why." If the product managers keep getting a "No" or "Maybe" for most of their ideas from engineering partners, it can quickly break the trust relationship between the two teams. It is essential to understand that technical strategy is often not about using the latest technology for product development. Nor is it about finding the best or most innovative plan for development. As a matter of fact, these emerging innovative tech stacks come with their own burden of scalability and integration restrictions. Additionally, such integrations can create an over-dependency on the development team for any bug fixes or new features due to the educational gap. Trying to focus on developing the most innovative tech strategy can result in a future of the "wrong" kind of technical debt and can hamper the future of product and customer growth. Speed is also a critical factor, considering the rapid pace of market evolution. With such hasty changes in customer behavior, the once visionary product can quickly become obsolete if not manifested fast enough. In my experience, the best technical strategies are the ones that focus on faster execution without adding additional friction of tech debt. The goal here is for engineers to focus on what we can build, edging the umbrella of current constraints instead of focusing on what we cannot. That is how we will foster a trustable partnership between the product and engineering teams and deliver groundbreaking products. Working Through the Feasibility Gap Working through the gap between the product vision and technical strategy is not about compromising the product vision, but rather about creatively adapting it to align with technical limitations, potentially creating a better product-market fit. In the process of working on these groundbreaking products, there will be several scenarios where an agile trifecta of flexibility, adaptability, and continuous feedback can help achieve the product vision or save engineering efforts from going adrift. In a rapidly evolving tech market, If the product needs change faster than your product can actualize any value, an agile approach will allow you to gather feedback quicker and refine your product to meet the evolving market needs. Innovative products often come with a factor of "unknown," such as technological constraints, economic shifts, or regulatory changes. An agile approach can help you respond faster to such unexpected disruptions. Even if the interruption is internal, such as a change in leadership priorities, or if the launched product does not meet leadership expectations, the results can be disappointing, but this is where an agile approach to roadmapping can save a lot of potential churn and overhead. We must not forget the importance of open-ended communication and collaborative working environments. When engineering teams understand why they are building something and how it helps the business, they will always propose better solutions to bridge that gap. Overall, an Agile approach will enable the creation of a more responsive and adaptable MVP timeline, allowing the project to progress responsively and iteratively. The product roadmap can be planned into measurable milestones that can be tracked via shared metrics. Such a structure will help teams create more realistic and responsive timelines, progressively closing the gaps to match the evolving product vision. Conclusion: Examples of Successful Deconstruction of Product Vision Into Actionable Goals That Align With Technical Feasibility 1. Spotify's Personalized Playlists Spotify transformed its vision of providing highly personalized music experiences into actionable goals by leveraging data engineering and machine learning technologies. They broke down the vision into smaller, feasible projects like the Discover Weekly feature, focusing on algorithms that analyze user behavior to suggest new music tailored to personal tastes. 2. Airbnb's Global Expansion Initially, Airbnb aimed to provide an alternative accommodation option for guests attending a conference in San Francisco. This initial concept evolved into a platform connecting travelers with hosts offering short-term accommodations. Recognizing the technical and operational challenges of global scaling, they deconstructed this vision into small and quickly actionable goals, such as establishing local market strategies and adapting the platform to support different languages and handle payment complexities. This approach allowed Airbnb to address the logistical hurdles of international expansion systematically. 3. Tesla's Electric Vehicle Production Tesla's success can be widely attributed to its intelligent and phased alignment of product vision with technical feasibility. Tesla had a very clear product vision of moving the world towards sustainable energy solutions while emphasizing electric vehicles. They used their in-house expertise in lithium-ion battery technology to gain a competitive edge and challenged the norms of the traditional automotive industry by showcasing "software-driven" vehicles. Planning a vertical integration strategy and constantly providing a superior user experience allowed Tesla to plan and incrementally overcome technical barriers, including battery cost reduction and introducing enhanced capabilities via software updates over time. These examples clearly show how aligning product vision with technical strategy is paramount to driving innovation and how deconstructing these visions into technically feasible goals allows companies to systematically approach complex challenges and achieve success in their product development journeys.

Here is how I became a software engineer without a computer science degree. Let me be real with you: coding was hard. I wasted so much time fixing missing semicolons, mismatched brackets, and misspelled variables. Even when the code was compiled, it would not work as expected, and I would spend hours staring at the screen and questioning my life choices. But over time, I picked up some strategies that made coding click for me, and I'm going to share these strategies with you today. Don’t Try To Know Everything The first thing I learned was that as a programmer, you don't need to know everything. When I began my first programming job, I was unfamiliar with Linux commands. When I joined Amazon, I did not fully understand G. At Amazon, my first project was in Python, and I had never written a single line of code in Python. Later, when I joined Google, I could not program in C++, but most of my work was in C++. The point I'm trying to make is that you don't need to know everything; you just need to know where to find it when you need it. But when I was a beginner, I would try to do these 30-40 hour boot camps to learn a programming language, thinking that I was going to learn everything. In reality, you cannot learn everything there is to learn. So, do not wait until you have the right skills to start your project; your project will teach you the skills. Do not wait until you have the confidence to do what you want; the confidence will come when you start doing it. Focus and Avoid Overwhelm Well, a successful warrior is an average man with laser-like focus. The same is true for a programmer, but it's really hard for a beginner to stay focused. That's because a programmer has more choices than a buffet at an Indian wedding. First, they have to choose a programming language. After that, they need to pick a course to learn that language. If they want to learn front-end development, they have all these choices, and for back-end developers, there is a whole other set of options. The more options available to a person, the longer it takes to decide which option is best. This is also called Hick's Law. As a beginner, it can be tempting to learn a little bit about many different technologies. After all, there are so many exciting areas to explore. While broad exposure is good, it's important for beginners to pick one technology stack to focus on initially. Mastery takes time and repetition, so go deep and not wide. Programming concepts take time to fully click. By focusing on one technology, you can iterate on the fundamentals again and again until they become second nature. Usually, you need to know one technology stack really well to get hired. Breadth is great, but you'll be evaluated on how well you know a specific technology that the job requires. Develop Problem-Solving Skills Next, the lesson was not to just focus on coding ability, but also on developing a problem-solving mindset. You see, coding is ultimately about solving problems, big and small. But the issues we solve as developers don't come prepackaged as coding problems like you see on LeetCode or in coding interviews. They come disguised as open-ended product requirements, refactoring challenges, or performance bottlenecks. Learning to deconstruct these messy real-world issues into solvable chunks is a key skill that you need to build. Example of Problem Solving Let's say there are thousands of users on the internet browsing for a dilution ratio calculator for car detailing products. They are wondering how much water should they add to the car detailing products based on the known ratio of detailing products and water. For this purpose, you can make a dilution ratio calculator in HTML, CSS, JS, or whatever language you prefer. But we recommend Python over HTML, CSS, and JS because you will need to write fewer lines of code. It was just one example: there are hundreds and thousands of problems that need to be solved. Techniques for Better Problem Solving Let me tell you two techniques that helped me become better at problem-solving. The first is the Five Whys analysis. This technique was created at Toyota as a way to identify underlying reasons behind manufacturing defects. Here is how it works: when you encounter a problem, you ask "why" five times, one after the other. Each answer forms the basis of the next "why." For example, let's say your code is running slower than expected. Why is that happening? Because it's taking a long time to process a large data set. But why? Because I'm using two nested loops to search for a specific value. And why is that? Because I thought that nested loops were the easiest way to solve the problem. Why is that? Because I do not know more efficient search algorithms. But why? Because I've not taken the time to study data structures and algorithms. By the time you get to the fifth "why," you have reached the core issue. The second technique I use is the separation of concerns. The main idea behind this is to break a complex problem down into smaller, manageable parts. For example, let's say you are building a web app with user authentication. You can break this problem down into multiple tasks, like building a user interface for login and registration, database management for storing user credentials, and authentication logic for verifying user identity. This makes the problem easier to process without getting overwhelmed. Building strong problem-solving skills will also help you in coding interviews. In coding interviews, they will ask you questions based on data structures and algorithms. These questions are designed to test your logical thinking and problem-solving. Stop Obsessing Over Syntax The next thing you need to do is to stop obsessing over the syntax. As I mentioned at the beginning of this article, I would constantly get frustrated by silly syntax errors. I would spend hours just trying to get my code to run without any errors. But then I realized that obsessing over the syntax is pointless. Syntax is just the grammar of the language; it's important, but not the core of coding. As we discussed, the core is problem-solving — breaking down a complex problem into simple steps that even a computer can understand. That's why I started practicing coding with pseudocode first. Pseudocode lets you mock out your solution in plain English before trying to write proper code syntax. It forces you to truly understand the logic of your solution upfront. Once I had that down, the actual coding became much easier because I just had to translate my logic into whatever language I was using. Here is an example of pseudocode for the fizz fizz game: Pascal style: procedure fizzbuzz; for i := 1 to 100 do print_number := true; if i is divisible by 3 then begin print "Fizz"; print_number := false; end; if i is divisible by 5 then begin print "Buzz"; print_number := false; end; if print_number, print i; print a newline; end C style: fizzbuzz() { for (i = 1; i <= 100; i++) { print_number = true; if (i is divisible by 3) { print "Fizz"; print_number = false; } if (i is divisible by 5) { print "Buzz"; print_number = false; } if (print_number) print i; print a newline; } } Python style: def fizzbuzz(): for i in range(1,101): print_number = true if i is divisible by 3: print "Fizz" print_number = false if i is divisible by 5: print "Buzz" print_number = false if print_number: print i print a newline Write Code for Humans, Not Computers Another thing I wish I had learned early was to write code for humans, not computers. A study done by Chajang University found that developers spend 58% of their time just trying to understand the code they are working with. As beginners, we tend to write code that works in a way that only makes sense to us. But effective code needs to be understandable by any developer who looks at it, including your future self. I cannot tell you how many times I came back to my code from a week ago and could not understand it myself. So, writing clean, readable code with proper variable naming, code formatting, and comments can massively boost your productivity as a developer. It's a skill I worked very hard to build by studying coding best practices and getting code reviews. Trust me when I say this: your future self will thank you for writing readable code. Master Debugging Techniques In talking about understanding code, the next thing that made my life easier was learning debugging. I can't tell you how many hours I wasted just randomly tweaking code, compiling, running, and tweaking again in the hopes that it would magically work. I thought that was the only way to do it. But then I read this article by Devon H. O'Dell that talked about how developers spent somewhere between 35% to 50% of their time debugging. That's over a third of their time. So, I decided to get serious about learning debugging. I learned how to use a debugger, adding log statements systematically, and recreating issues in smaller isolated cases. Learning and applying a proper debugging process saved me a lot of time and headaches. Most code editors have built-in debugging functionality. In certain cases, you can also use a third-party extension like ReSharper. To learn more about debugging, check out Google's troubleshooting and debugging techniques course on Coursera. Enroll for free! Focus on the Little Things And this brings me to the most important lesson. Back in the 1980s, American Airlines was looking for ways to cut costs and improve its profit margin. Bob Crandall, who was the head of American Airlines at the time, decided to take a closer look at the airline's food service. He noticed that the salads being served on the flight included a garnish of three olives per salad. Bob did some quick math and figured out that if they removed just one olive from each salad, they could save a substantial amount of money. Keep in mind that American Airlines was serving thousands of meals every day, so even though one olive might not seem like much, the numbers added up fast. American Airlines saved around $40,000 per year in today's dollars by doing this (Ref). The lesson here is that sometimes the biggest improvements come from paying attention to the little things. Incremental Improvements In his book Atomic Habits, James Clear talks about the power of making small, incremental changes in life (ref). The idea is that tiny habits, when compounded over time, can lead to remarkable results. He shows that just a 1% improvement every day over one year can make you 38 times better. The key to making these improvements is starting small. So, if you want to get in shape, start by doing one push-up per day. If you want to read more, start by reading just one page every night. And if you want to learn programming, start by doing just two exercises per day. Over time, these small improvements will compound. Two exercises will become 20, and 20 exercises will become one project, and so on. Whatever you do, you cannot have anything worth having without struggle. And if you're struggling to learn programming, you are on the right track.

During my 10+ years of experience in Agile product development, I have seen the difficulties of meeting the rapid requirements of the digital market. Manual procedures can slow down highly flexible software engineering and delivery teams, resulting in missed chances and postponed launches. With AI and Large Language Models (LLMs) becoming more prevalent, we are on the verge of a major change. Gartner points out a 25% increase in project success rates for those using predictive analytics (Gartner, 2021). These technologies are changing the way agile product development is optimized - by automating tasks, improving decision-making, and forecasting future trends. As stated in a report from McKinsey, companies using AI experience a 20% decrease in project costs (McKinsey & Company, 2023). In this article, I discuss how agile product development including any experiences and user journeys can be improved based on AI and LLM integrations across the development lifecycle. Also Read: "The Foundation of AI and Analytics Success: Why Architecture Matters" AI and LLM Integration Phases for Agile Product Development Automating User Story Generation Creating user stories is crucial for Agile development, although it can be time-consuming. LLMs, for example, such as GPT-4 from OpenAI are able to streamline the process by creating comprehensive user stories using available documentation and feedback. This speeds up the process while also enhancing precision and significance. Application Scenario For example, I focus on utilizing AI or LLM-based methods for streamlining, optimizing, and automating the creation of user stories. Integrating such methods with a comprehensive backlog has allowed me to improve product development lifecycles and any engineering prioritization. This significantly reduces user story creation time, which is also helpful for solutions architects and increases user satisfaction where there is more relevant and accurate feature development. Significance and Advantages The automation of generating user stories is essential as it reduces the monotonous job of creating stories by hand, enabling product managers and software engineers to concentrate on more strategic tasks. This process guarantees that user stories are created uniformly and in line with user requirements, resulting in improved prioritization and quicker development cycles. Assisting agile teams in sustaining their progress and releasing features that better align with user needs. Additionally, organizations that adopt AI for generating user stories usually see a 50% reduction in story creation time (Menzies & Zimmermann, 2022). Also Read: "User Story Reflections" Optimizing Backlog Prioritization Key to swift value delivery is effective prioritization of the backlog. AI algorithms analyze user feedback, market trends, and technical dependencies to forecast the most valuable features. This approach driven by data assists product managers in making well-informed choices. Application Scenario For example, during the development of a digital healthcare consumer platform, I utilized AI tools to review user feedback and determine which backlog items to focus on first. This was mapped across different prioritization techniques as well as how engineering would execute them based on complexity. As a result, there was a 40% rise in feature utilization and a 20% decrease in feature development duration, which also helped the software engineering team improve their metrics. Significance and Advantages It is crucial to prioritize backlog optimization in order to make informed decisions that improve the value of the product and customer satisfaction. Utilizing AI for prioritization aids agile teams in determining which features will yield the greatest benefit, enabling them to utilize resources effectively and concentrate on tasks with significant impact. Companies that have implemented AI for prioritizing their backlog have seen a 40% growth in feature adoption (Buch & Pokiya, 2020). Leveraging Predictive Analytics Predictive analytics offers insight to help shape development tactics. AI models can predict risks and estimate delivery times by examining historical data, helping teams address issues and align development efforts with market changes. Further, this can help agile product development teams assess how to staff across sprints and ensure workforce optimization to improve feature velocity. Application Scenario For example, I use predictive analytics in collaboration with engineering development and delivery teams to predict how new features would affect Sprint planning, Sprint allocation, and user engagement. The information assisted in determining which updates were most important as well as need execution in upcoming sprints and has allowed me to optimize MVPs, resulting in a ~25% rise in user retention and a ~15% increase in new user acquisition across two different products. Significance and Advantages Predictive analytics offer practical insights that steer strategic choices in flexible product development. Teams can prioritize new features that will have the greatest impact on user engagement and retention by predicting their effects. Businesses that use predictive analytics have observed a 25% rise in customer retention (Forrester, 2019). Improving Product Experiences and User Journeys AI and LLMs improve user journeys and product experiences through a more user-focused approach to development. Automated creation of user stories guarantees that features are developed according to genuine user requirements, resulting in products that are more instinctive and captivating. This alignment improves user satisfaction and involvement by customizing features to meet specific needs and desires. Use Case For example, I used LLMs to analyze user feedback and create features that directly addressed user pain points. This resulted in streamlining and optimizing how different product features are lined up along with tech debt for engineering execution. I have seen a ~35% increase in user engagement significant reduction in user churn rates. Significance and Advantages Improving product experiences and user journeys with AI and LLMs ensures a user-focused approach in product development, resulting in more user-friendly and personalized experiences. Aligning with user needs not only boosts satisfaction but also enhances engagement and retention. After incorporating AI-driven improvements, companies have experienced a 35% rise in user engagement (Ransbotham, Kiron, Gerbert, & Reeves, 2018). Supporting Agile Product Development and Product Management Incorporating AI and LLMs into agile product development changes how teams tackle and carry out projects, providing numerous advantages. To begin with, these technologies simplify the process of developing user stories, cutting down on manual work and allowing more time for strategic duties. This results in enhanced precision and significance in feature advancement. Also, by using AI to prioritize the backlog, teams can concentrate on important tasks, leading to better use of resources and increased overall productivity. Predictive analytics enhances value by predicting feature performance, allowing teams to make educated decisions that increase user retention and engagement. From my own experience, I've noticed that these advancements not only speed up the process of development but also make products better suited to user requirements, resulting in a more agile and adaptable development setting. The integration of AI in agile product development leads to improved product management, faster iterations, and enhanced user experience. For example, the global AI-assisted custom application development market is expected to grow up to $61Bn and from 21% to 28% by 2024 (Deloitte Insights, 2020). As a product manager working across multiple software engineering teams, AI and LLMs have helped me simplify decision-making by automating routine tasks and providing actionable insights. Automated user story generation and backlog prioritization free up time to focus on strategic aspects, while predictive analytics offers data-driven forecasts and trend analysis. This results in a more agile and responsive product management process, where decisions are guided by comprehensive data and real-time insights, ultimately leading to more successful product outcomes and better market alignment. Benefits of AI and LLMs for Agile Product Development Conclusion and Next Steps The incorporation of AI and LLMs in agile product development seems like a dynamic revolution. In my opinion, these tools have revolutionized the way tasks are done by automating them, streamlining processes, and forecasting trends accurately. They have made workflows more efficient and enhanced product experiences, resulting in more agile and responsive development cycles. As we further accept and improve these technologies, I look forward to witnessing how their developing abilities will continue to change our strategy for creating and providing outstanding products. The process of incorporating AI and LLMs into agile product development methods is indeed exciting and filled with potential. Key Takeaways Start using AI and LLM tools to automate and improve the generation of user stories and prioritize backlogs in your development processes.Utilize predictive analytics: Employ predictive analytics to gain insight into potential project risks and market trends, enabling proactive modifications.Prioritize user-centric development: Utilize AI-generated insights to enhance product experiences for better user satisfaction and retention.