Career Development

Conflicts in the workplace are nearly unavoidable. Picture this: a development team is racing to meet a tight deadline, only to clash with the QA team over testing requirements that might push the release back. Instead of moving closer to completion, you find yourself speeding into a wall of frustration and missed deadlines. These scenarios are all too familiar — studies show that the more interactions team members have, the higher the likelihood of conflicts. Some researchers even quantify the hours spent in these disputes, with the average reaching several hours each week. While it’s true that constructive conflict can sometimes spark creativity, the reality is that most workplace tensions are counterproductive, leading to stress and disengagement. So, how well-prepared is the average manager to handle these situations? Let’s be honest — many managers are promoted based on their technical skills or good relationships with superiors rather than systematic training in conflict resolution. It’s a risky gamble, relying solely on a manager’s intuition and emotional intelligence without proper support. The chances of repeated issues are high. Fortunately, there’s a way forward. Social psychology, the study of how individuals and groups interact in their social environment, offers valuable insights into the roots of conflicts and strategies for managing them effectively. This article aims to explore how engineering managers can apply these principles to better understand, manage, and resolve conflicts within their teams. Psychological Roots of Conflict Psychologists identify several common causes of conflict: social dilemmas, competition, perceived injustice, and misperception. While this isn’t an exhaustive list, these categories cover most of the typical reasons behind workplace conflicts. The nature of these issues is complex and multifaceted, but by understanding these four key areas, managers can better navigate the storm of misunderstandings and guide their teams back to a path of productive collaboration. Let’s dive into each of these in detail. Social Dilemmas A social dilemma arises when individuals, in pursuit of their own self-interest, create outcomes that ultimately harm the larger group. In a workplace setting, this often happens when employees or departments prioritize their own goals at the expense of the company’s overall objectives. Social dilemmas are typically categorized into two types: the Prisoner’s Dilemma and the Tragedy of the Commons. Prisoner’s Dilemma This dilemma emerges when individuals face a choice between cooperation and acting in their own self-interest, with the risk that prioritizing self-interest results in worse outcomes for everyone involved. The core issue lies in mistrust — people fear that cooperating might threaten their job security, so they choose self-preservation, even when cooperation would have been more beneficial for the group. In practice, an example of the Prisoner’s Dilemma at work is when employees are reluctant to share knowledge. They might believe that keeping valuable information to themselves enhances their job security. For instance, if a senior engineer refuses to document their work or train less experienced colleagues, they may feel more indispensable. However, if all team members adopt this approach, the organization ends up with siloed knowledge, leading to inefficiencies and slowing overall progress. Tragedy of the Commons This occurs when individuals overuse a shared resource, leading to its depletion or degradation. When everyone acts to maximize their immediate gain without considering the long-term impact on the resource, the entire group suffers. A common example of the Tragedy of the Commons occurs when multiple teams share a limited resource, like a testing environment. Imagine development, QA, and DevOps teams all relying on the same infrastructure for testing and deployments. Each team, aiming to speed up their workflow, might overuse the resource by reserving it extensively to meet their own deadlines. While this may seem logical for each team, it leads to congestion, bottlenecks, and slowdowns across the organization, turning the shared resource into a point of conflict. These examples highlight social dilemmas — situations where short-term, self-serving actions lead to negative long-term consequences for the entire organization. Competition Competition arises when groups or individuals vie for limited resources, opportunities, or recognition. In the workplace, these resources can take many forms — budgets, promotions, project ownership, or the visibility of achievements. When the stakes are high, and the outcome is seen as a zero-sum game, tensions can escalate rapidly, leading to a breakdown in collaboration. A common example is when different departments compete for a limited budget. Picture this: the product team insists that most resources should go into new feature development, believing this will maximize immediate impact and demonstrate their value. Meanwhile, the engineering team argues that a significant share of the budget should be devoted to stabilization efforts or routine operations — investments that may not yield immediate results but are critical for ensuring long-term reliability and performance. As each team pushes for its priorities, the competition over funding intensifies. If a compromise isn’t reached or the organization fails to mediate effectively, the result could be an imbalanced outcome: a feature-rich product plagued by technical issues or resources diverted into maintenance without delivering immediate business value. When competition escalates like this, it often fosters an “us vs. them” mentality, further deepening the collaboration crisis and disrupting team unity. Perceived Injustice This is a fairly straightforward category, where conflicts often lead to resentment and disputes. The challenge lies in the fact that what is considered “fair” varies based on individual perceptions, cultural backgrounds, and moral values. In multicultural teams, people may have different views on fairness — some see it as equality (everyone receives an equal share), while others view it as equity (rewards are distributed according to individual contributions). Consider a situation where two engineers, Frank and Peter, are both up for a promotion. Frank consistently takes on challenging projects, works overtime, and demonstrates leadership qualities. Meanwhile, Jamie has focused on less visible tasks but has been with the company longer. When the promotion is announced, it goes to Jamie, as the decision is primarily based on tenure. From Frank’s perspective, this is a clear injustice. He believes that promotions should be equity-based. However, the company’s decision aligns with a seniority-based approach, valuing loyalty and tenure. As a result, Frank feels hurt, believing that his efforts and contributions have been overlooked. Such conflicts arise when there is a fundamental disagreement not only about what fairness means but also about how it should be measured. Employees with different values, levels of experience, or tenure often hold opposing views on what constitutes a fair reward system. Misperception Misperception is an inherent part of human nature. Our minds are wired to quickly interpret information based on availability, representation, and a range of biases that each of us carries. Often, a small disagreement can escalate when each side begins to misinterpret the other’s motives and intentions, amplifying the conflict. In the workplace, these misperceptions can distort interactions among colleagues, teams, or departments, leading to misunderstandings that grow into larger issues. Social psychology highlights several common biases that contribute to these misperceptions: Self-serving bias: Individuals tend to take credit for successes while deflecting blame for failures, which causes them to view their own actions more favorably.Fundamental attribution error: People often attribute others’ negative actions to their character (e.g., “they’re unreliable”) rather than considering external factors that might be influencing their behavior.Ingroup bias: Groups frequently see themselves as moral and just while perceiving others as wrong or even hostile.Mirror-image perceptions: Conflicting groups often hold opposing views of each other, with each side believing it is virtuous while the other is in the wrong. These biases can lead individuals and teams to interpret others’ actions in the worst possible light, turning minor misunderstandings into significant conflicts. Take, for example, a project where the development and product teams are collaborating to launch a new feature. The development team wants more time to refine the backend infrastructure to ensure stability, while the product team pushes for a quick launch to meet market demands. Both teams have legitimate goals, but as pressure mounts, each begins to misinterpret the other’s motives. The development team may start believing that the product team only cares about speed, disregarding quality and perceiving it as reckless. On the other hand, the product team might see the development team as overly cautious and inflexible, interpreting their actions as a lack of commitment to the project’s success. These misperceptions amplify the conflict, as each side starts viewing the other not just as having different priorities but as actively undermining the team’s overall objectives. What Do These Conflicts Have in Common? If we delve deeper into psychology, most workplace conflicts stem from the interaction of three psychological factors: identity, perception, and bias. Social psychology provides a framework for understanding these conflicts and offers insights into how they often manifest within teams. Social Identity Theory: The “Us vs. Them” Mentality Organizations are composed of groups that operate within specific areas of responsibility — departments like marketing, sales, or software development, as well as specialized teams within those departments (e.g., development, testing, or product teams). While these distinctions are essential for collaboration, they also create a sense of belonging to a particular group. This phenomenon, known as the ingroup versus outgroup mentality in psychology, influences how employees perceive and prioritize their work. When team members strongly identify with their subgroup, they may prioritize its goals over those of the broader organization. For instance, engineers might feel a stronger loyalty toward their technical peers, advocating for technical quality and stability, while product managers focus on feature delivery and market demands. These divisions can intensify conflicts, especially when cross-group collaboration is crucial. Misunderstandings and insufficient communication between product and development teams are classic examples of how social identity theory plays out in practice. Cognitive Dissonance: Justifying One’s Position Cognitive dissonance arises when individuals encounter information or viewpoints contradicting their beliefs or attitudes, creating discomfort. In the workplace, this often happens when team members are presented with perspectives that challenge their long-held perceptions or strategies. To reduce the discomfort, they may vigorously defend their viewpoint or discount the new information entirely. Consider a situation where a marketing specialist insists that a particular campaign strategy has always been effective, while a data analyst presents evidence showing that the approach has been underperforming recently. The marketing specialist, experiencing cognitive dissonance, might dismiss the data as an anomaly or attribute it to external factors rather than reconsidering the strategy itself. This response, aimed at protecting their perception of the campaign’s success, makes it harder to accept alternative views or adapt to new evidence, complicating the search for a constructive solution. Biases: Interpreting Motives People often make quick judgments about others’ intentions based on limited information, which is a common source of conflict within teams. This tendency is rooted in attribution biases, where individuals attribute behavior to internal traits (e.g., laziness or incompetence) rather than considering external factors like tight deadlines or resource constraints. In workplace conflicts, these biases can escalate tensions as team members jump to conclusions about others’ motives. For example, if a developer misses a deadline, teammates might assume it’s due to a lack of commitment, ignoring the possibility that the developer is dealing with personal issues or unclear requirements. These biases can escalate minor issues into significant conflicts as team members begin viewing each other as uncooperative or irresponsible. In many cases, conflicts in engineering teams are less about the actual problem and more about how the situation is perceived. Biases such as confirmation bias and the fundamental attribution error play critical roles in shaping how team members interpret each other’s actions and intentions: Confirmation bias: This occurs when team members seek or interpret information that reinforces their pre-existing beliefs. For example, if a developer has had disagreements with a colleague in the past, they may focus on actions that confirm their negative view, even when those actions are neutral or positive.Fundamental attribution error: People often attribute others’ behavior to internal traits rather than external circumstances. In engineering teams, this might show up when a developer assumes a teammate’s failure to deliver on time is due to poor work ethic rather than recognizing external challenges, such as unexpected technical issues or conflicting priorities. It becomes evident that engineering managers must be aware of these categories and the underlying causes driving them. Understanding these dynamics is critical for managing people effectively and ensuring team success. Strategic Pathway to Conflict Resolution Now that we’ve identified the main causes and types of conflicts, the next logical question is: how do we resolve them effectively? In this section, we’ll explore general approaches to conflict resolution before diving into specifics for each type we’ve discussed. Managers often rely on a structured framework to navigate conflict resolution; in social psychology, this is called the “4Cs” framework: contact, cooperation, communication, and conciliation. These strategies are designed to bridge divides, promote understanding, and build collaborative relationships, ultimately transforming conflicts into productive outcomes. Contact Establishing meaningful and sustained contact between conflicting parties is a fundamental step in reducing prejudice and building familiarity. Facilitating interaction: Simply placing conflicting groups together can sometimes worsen tensions if not managed properly. Effective contact involves structured interactions that aim to reduce anxiety and foster empathy.Equal-status engagement: Interactions must occur under conditions of perceived equality. When individuals engage as equals, negative biases are more likely to diminish.Personal connections: Encouraging personal relationships through shared activities or experiences can humanize the “outgroup” and dismantle stereotypes. Cooperation While contact is essential to place everyone on a common ground, cooperation is necessary to turn simple interaction into a transformative outcome. Common goals: Setting superordinate goals — objectives that require both groups to collaborate—helps align interests and unify efforts.External threats: Sometimes, a shared external threat can unite previously conflicting groups. Recognizing a common challenge, such as an organizational crisis, can foster a sense of solidarity and shared identity.Success in collaboration: Cooperative efforts must be designed for success; failure can deepen divisions. Managers should ensure that initial cooperative initiatives are achievable and yield positive results. Communication Effective communication is the bridge between understanding and resolution. When tensions are high, facilitating open dialogue can break down barriers and promote empathy. Mediation and facilitated discussions: When direct communication is difficult, mediators can help conflicting parties voice their concerns, set shared goals, and find common ground.Controlled and empathic dialogue: Providing structured, non-threatening spaces for individuals to express their feelings and perspectives can help unravel misperceptions. Techniques like role reversal or perspective-taking exercises allow team members to see the situation from the other’s viewpoint.Transparency and trust building: Open, honest, and transparent communication channels are essential. Regular dialogue helps prevent misunderstandings and reduces the likelihood of conflicts escalating. Conciliation When communication and cooperation alone aren’t enough to resolve deep-rooted conflicts, conciliation strategies can be effective in de-escalating tensions. One such method is GRIT (Graduated and Reciprocated Initiatives in Tension Reduction), which can help break cycles of retaliation. Initiating small, unilateral acts: One party takes the first step by offering a small gesture of goodwill, such as reducing demands or offering resources. These actions must be framed with transparency to build trust and encourage reciprocation.Reciprocal de-escalation: The goal of conciliation is to create a positive feedback loop, where each side gradually reciprocates and builds on the other’s efforts. Small, verifiable actions reduce tensions incrementally, avoiding destabilizing changes.Balancing firmness and flexibility: Conciliation is about cooperation, but not at the cost of important principles. It’s critical for parties to maintain a firm stance on key issues to prevent exploitation while showing flexibility where compromise is feasible. For managers, operating within this strategic pathway is beneficial and essential for effectively resolving conflicts and fostering collaboration. As mediators and facilitators, managers play a critical role in establishing structured communication, facilitating cooperation, and guiding teams through contact and conciliation processes. By setting up controlled interactions, promoting shared goals, and encouraging open dialogue, managers can transform conflicts into opportunities for growth. Their ability to navigate these dynamics and implement the 4Cs framework is pivotal for building trust, reducing tensions, and aligning teams with the organization’s broader mission. Success in conflict resolution hinges on the manager’s active involvement in creating an environment where differing perspectives are reconciled and turned into strengths. Techniques to Resolve Root Causes of Conflicts Each type of conflict (social dilemmas, competition, perceived injustice, and misperception) demands a distinct approach. While some techniques are effective across multiple conflict types, addressing the specific dynamics of each is crucial for effective management and resolution. This section offers targeted strategies for each conflict type, followed by general techniques applicable across situations. Techniques for Resolving Social Dilemmas As discussed earlier, social dilemmas arise when individuals act in self-interest, leading to negative outcomes for the larger group. Here is how you can manage and resolve these dilemmas: Implement Regulations and Policies Establish clear rules and guidelines that align individual actions with collective goals. In the workplace, these might include: Setting usage quotas for shared resources to prevent congestion and ensure fair access.Creating policies for knowledge sharing and collaboration to encourage openness and reduce information silos. Promote Small Group Collaboration Breaking larger teams into smaller, focused units (e.g., task forces or squads) can foster a sense of ownership and accountability. These smaller groups are more likely to cooperate when members feel their actions directly impact the group’s success. Adjust Incentives to Encourage Cooperation Managers can design incentives that reward team collaboration over individual achievements: Offer bonuses or recognition for team-wide accomplishments rather than focusing solely on individual metrics.Provide tangible benefits for departments or teams that demonstrate successful collaboration and resource sharing. Techniques for Resolving Competition The strategies below help manage and resolve conflicts arising from competition: Establish Transparent Resource Allocation Systems To prevent conflicts over resources like budgets, staffing, or project ownership: Implement clear criteria for resource distribution that are communicated openly to all teams. This promotes fairness and reduces suspicion or resentment.Engage teams in collaborative decision-making processes where representatives from each team can voice their needs and negotiate compromises. Create Opportunities for Collaborative Wins Shift the competitive mindset by reframing goals to encourage cooperation: Design projects that require multiple teams to work together, making success dependent on collective performance.Develop joint recognition programs that celebrate cross-departmental achievements, incentivizing teams to cooperate instead of competing. Facilitate Mediation and Conflict Resolution Sessions When competition intensifies, managers should act as mediators: Lead mediation sessions where conflicting parties can express their concerns and work toward a mutually acceptable solution.Use facilitation techniques that focus on understanding each team’s priorities and finding a compromise. Techniques for Resolving Perceived Injustice Perceived injustice occurs when team members feel undervalued or unfairly treated, affecting morale and productivity. Here is what you can do about it: Foster Transparency and Open Communication One of the most effective ways to reduce perceived injustice is ensuring decision-making processes are transparent: Hold open forums or Q&A sessions where management explains the reasoning behind decisions related to promotions, budgets, or role changes.Allow employees to express their concerns and provide feedback in these sessions, helping them feel heard and valued. Implement Fairness Policies and Structured Evaluation Criteria Establish clear criteria for performance evaluation, rewards, and promotions.Train managers on providing constructive and objective performance evaluations. Offer Grievance and Mediation Channels Create formal channels for employees to raise concerns about perceived injustices: Develop a grievance procedure that allows employees to report issues confidentially, providing a safe space for conflict resolution.Set up mediation services where neutral parties offer objective perspectives and solutions to resolve conflicts. Techniques for Resolving Misperception Misperceptions occur when team members misinterpret others’ intentions or motives, leading to conflicts and misunderstandings. The following strategies help correct these misperceptions and promote a culture of open dialogue: Organize Perspective-Sharing Workshops Workshops that focus on perspective-taking can help team members understand each other better: Conduct sessions where team members share their work processes, challenges, and priorities to build empathy and reduce biases.Use role-playing exercises that allow individuals to step into their colleagues’ shoes, promoting greater understanding and reducing misperceptions. Facilitate Constructive Feedback Loops Encourage regular feedback sessions where teams express their views openly: Implement 360-degree feedback systems that allow employees to give and receive feedback from peers, subordinates, and supervisors.Train team members on providing constructive, non-judgmental feedback to ensure these sessions are productive and not confrontational. Promote Cross-Functional Collaboration Encouraging collaboration between teams helps break down silos and reduce misperceptions: Rotate team members across projects to expose them to different work styles and roles, building familiarity and reducing biases.Set up cross-functional meetings where teams can openly discuss their work and goals. How to Apply the Knowledge Above Managing conflicts effectively requires a structured approach that treats each situation as unique while applying established techniques and principles. Here’s a concise algorithm to manage any conflict, regardless of its type: Initial Assessment and Contextual Understanding Identify the Conflict Type Determine if the conflict stems from a social dilemma, competition, perceived injustice, or misperception. Understanding the nature of the conflict will help guide the appropriate resolution strategy. Set the Context Understand the broader environment in which the conflict has emerged. Contextual factors will shape your approach. Define Objectives Establish what a successful resolution would look like for both the team and the organization. Gather Information and Conduct Forensics Collect Background Information Gather details about the history of the conflict, including past interactions and the current situation. Engage with Observers Speak with colleagues who may have witnessed the conflict or have insights into the parties involved. Their observations can clarify motives and help build a timeline. Analyze the Root Cause Use the gathered information to identify the underlying issue (e.g., a social dilemma like resource allocation, competition over recognition, perceived unfairness, or a misperception of motives). This is crucial for selecting the appropriate resolution techniques. Engage with the Conflicting Parties One-on-One Conversations Meet with each party separately to understand their perspective and emotions. Allow them to express their side openly, asking clarifying questions to ensure you accurately capture their motives and concerns. Identify Common Goals Look for shared objectives or interests during these discussions that can be leveraged later for resolution. Set Expectations for Resolution Inform the parties about the resolution process, emphasizing the importance of cooperation and open communication. Facilitate a Joint Meeting (if Appropriate) Establish Ground Rules Create a safe space where both parties feel respected, setting rules like no interruptions, respectful language, and equal speaking time. Apply specific techniques: For conflicts rooted in Social Dilemmas (e.g., resource sharing), emphasize the importance of collaboration and work on aligning group goals.If the conflict involves Competition (e.g., competing for recognition or resources), encourage a shift in focus toward shared objectives and foster a cooperative mindset.For issues of Perceived Injustice, create opportunities for open discussion where parties can express their grievances and work towards understanding each other’s viewpoints.In cases of Misperception, use perspective-taking exercises or role reversals to help parties understand the intentions and constraints of their counterparts. Mediate the Conversation Encourage parties to express their views and restate each other’s points to build understanding. If tensions are high, use strategies like GRIT to de-escalate and foster cooperation incrementally. Develop a Resolution Plan Identify Mutually Beneficial Outcomes Aim for a solution where both parties feel their needs are acknowledged. Use specific strategies tailored to the conflict type. Draft a Plan of Action Develop an action plan that outlines concrete steps each party will take, such as behavior changes, adjustments to responsibilities, or implementing new communication norms. Set Review Points Agree on follow-up meetings to monitor progress and make necessary adjustments. Monitor and Adjust Regular Check-Ins Monitor the situation over time to confirm the resolution is effective. Encourage Positive Reinforcement Acknowledge improvements and celebrate cooperation when progress is made. By following this structured algorithm, managers can systematically investigate, engage, and resolve conflicts in a manner that is fair and effective. Summary Workplace conflicts are inevitable, arising from complex dynamics like identity, perception, bias, and miscommunication. For managers aiming to resolve these conflicts effectively, understanding their underlying causes is essential. This article explored various types of conflicts (social dilemmas, competition, perceived injustice, and misperception), highlighting the distinct strategies required for managing each. By leveraging frameworks like the “4Cs” (contact, cooperation, communication, and conciliation), managers can systematically address and mitigate tensions. The structured approach provided offers a clear algorithm, enabling managers to treat each conflict as a unique case while applying consistent, evidence-based principles. For managers, mastering these techniques is crucial. Success in conflict management ultimately hinges on a manager’s ability to create an environment where differences are understood, respected, and leveraged to drive success.

Explore the practical challenges organizations face in providing on-the-job training aligned with an employee growth path for experienced R&D professionals while enhancing customer experience through improved quality and a focused approach to customer use cases. This article introduces an idea to address both of these challenges by introducing or expanding the role of a Feature Owner in an organization, which can be a win-win situation for both businesses and an individual aspiring to be an Architect or Product Manager. A Feature Owner is an internal role, responsible for facilitating an end-to-end delivery of a feature or requirement of a product. Individual(s) being promoted to this role should have experience and seasoned professionals from an R&D background who have witnessed challenges in managing expectations with customer use cases and intend to grow into an Architect or Product Manager role. Promoting these experienced individuals to act as a Feature Owner can bring much-needed focus, innovation, and responsibility to the end-to-end development of a feature within an agile team. With this approach, slowly and gradually, we can prepare them for his/her next role. Also, organizations will gain in reskilling an existing employee on the job with a much-needed customer perspective and technical focus on the feature or a requirement. Along with re-skilling, we are creating a talent pool with individuals exposed to stretch assignments for real-world experience, thus preparing them for their next role. Finally, an organization can gain by using their experience to improve overall quality and customer experience. Introduction With the growing global landscape, this article talks about how to address organizational challenges in improving customer experience at the get-go of any project. Aligning this with employee growth would make it a successful recipe for both the organization's and employee’s growth visions. The goal is to cultivate individuals who can consistently and effectively engage in reflective practice. Reflective practice is not merely looking at the surface, but an introspection. An individual should look inward and consider his/her knowledge, experience, and behavior. This is invaluable, even in the best agile workplace where we’re encouraged to pause for thought and reflection. If we never step back and think deeply, we end up being reactive. The emphasis on “even in the best” is because thinking in a group, under time pressure, doesn’t produce deep learning in an individual. It’s effective for quick “lesson learned” moments in an agile team, but rarely examines what was going on inside various individuals’ heads and how that contributed to a situation. People need space to go away and think at their own pace, in order to come back with more detailed reflection because that makes more agile individuals, who form a more agile team. Read along to delve into more details, as we introduce/expand on a Feature Owner role in an agile setup to help an individual practice and apply reflective thinking. Why the Feature Owner Role Is Essential Greater attention to feature development: Allows a person to be responsible for driving and mentoring feature development from an end-to-end perspectiveGrowth opportunity: Roadmap to upskill employees on the job with a focus on understanding customer needs and gaining in-depth system knowledge in feature development before they plunge into a Product Owner or Architect roleQuality and strategy: Step forward to elevate a seasoned R&D employee's role to own Quality at a Feature level, thereby contributing to long-term Product strategy and helping in identifying/reducing bugs in earlier stages of implementation.Decision making: Learning by being involved in decision-making, where he/she contributes to the overall product release strategy Overview of the Feature Owner Role Definition and Responsibilities A Feature Owner is an internal role, taken up by a seasoned professional, who actively facilitates an end-to-end development of a feature or requirement. Overview of responsibilities: Early defect identificationCustomer-focused and technically sound to guide a team during feature developmentInnovate and standardize practicesEnhance non-functional testingMentorship, strategic planning, and preparation for their next role Elevating Focus to Higher-Level Activities This initiative empowers experienced team members to transcend day-to-day tasks. It allows them to: Engage in strategic planning for future product roadmap.Dedicate time to mentorship and knowledge-sharing within the team.Understand customer challenges more deeply, there by prepare themselves for their role by acquiring leadership and decision-making skills.Understand the complete system and visualize their integration challenges beforehand. Advancing Experienced Members Elevating experienced team members sparks a strategic transformation by: Grooming of successors to get hands-on experience in managing day-to-day activitiesFacilitating continuous knowledge transfer within the teamEstablishing a template for creating backups, ensuring task continuity during absencesProviding an alternative path to those aspiring to go beyond the typical R&D career path Rotational Role Option In setups with a substantial number of experienced team members, this role can be a unique rotational opportunity. Team members can immerse themselves in this role for a set duration, with a minimum requirement of 2 years. This approach allows individuals to acquire diverse skills, fostering a comprehensive understanding of the system for better long-term perspectives. Tackling Limited Time for Continuous Improvement This expanded role can also help in addressing the challenge of limited time for continuous improvement by: Actively engaging in retrospective meetings to pinpoint areas for improvementLeveraging self-experience to swiftly suggest solutions for process enhancementsCollaborating with teams to implement improvements, ensuring a continuous cycle of learning and optimizationAn opportunity of self-grooming with hands-on exposure for the next career step The Liberation of Unique Reporting Structures Feature Owner members, reporting to a manager different from Sprint members, can experience a paradigm shift that grants them the freedom in an agile Sprint team to apply reflective thinking: Innovate without constraints: Leverage their creativity and innovative thinking without the limitations imposed by a manager of a Sprint teamProvide diverse contributions: Bring varied perspectives and solutions to challenges, promoting a culture of continuous improvementMentor effectively: Engaging in mentorship without the influence of a singular managerial viewpoint, enriching the learning experience for the entire team Advantages of Diverse Reporting for Feature Owners This is not mandatory for organizations exploring this path, but an idea to pitch this is for overcoming hierarchical challenges most traditional set-ups may introduce in getting major benefits out of this role. Below are the benefits: Empowering Innovation The freedom granted by diverse reporting structures empowers Feature Owner Members to step back for: Exploring unconventional solutions to complex problemsIntroducing novel practices that align with team dynamics and project requirements Authentic Mentorship Feature Owner members, reporting to different managers, can provide authentic mentorship by: Offering a variety of leadership insights from distinct managerial perspectivesCreating a mentorship dynamic that goes beyond a single managerial influence Cultivating a Culture of Continuous Improvement Diverse reporting structures contribute to a culture of continuous improvement by: Encouraging the exchange of diverse ideas and best practicesMitigating the risk of stagnant thinking by introducing a range of perspectives Implementation Plan Clear Role Definition Clearly define the expectations and value of this role, so that one can easily differentiate it from existing roles such as Scrum Master and Product Owner. Ensure the person moved into this role focuses on innovation, mentorship, continuous improvement, and self-learning to prosper further. Alignment With Agile Principles Ensure this role aligns with core Agile principles, such as collaboration, self-organization, and continuous improvement, without disrupting existing workflows. Training and Onboarding Provide comprehensive training to employee selected in this role, so that they understand how it fits in the Agile context, expectations, and how this can help them in shaping their future. Independent Performance Metrics Establish KPIs to evaluate performance, focusing on their contributions to process improvements, feature development to deployment, and team efficiency. Regular Feedback and Adaptation Implement mechanisms for regular feedback from team members and stakeholders to measure the role's effectiveness and evolve it further based on business needs. Cross-Functional Collaboration Encourage collaboration between Feature Owner, Scrum Master, Product Owner, and team members to ensure alignment and avoid role overlap. Pilot Program Introduce/expand this role as a pilot in a few teams to test its effectiveness and identify any potential issues. Management and HR Buy-In Ensure business management and HR understand the value behind this role and support it. Educate leadership and mid-level management team about the benefits, and how it complements existing Agile practices, in a way to promote this role, so that employees also feel engaged and start thinking about it. Measuring Success Gauging Triumph Through KPIs and NPS Score Key performance indicators need to be defined to measure the success of a Feature Owner role. They can have metrics related to defect resolution time, adherence to best practices, team velocity, overall enhancement of code quality, and the effectiveness of continuous improvement initiatives. Surveys Get feedback through anonymous feedback from a team about the role's effectiveness, and also feedback from employees taking up this role for fine-tuning the role and process. Finally… The industry is evolving, and so is the need for businesses to think out of the box. Without adding pressure on cost, grooming career paths with customer-centric and strategic decision-making training is a win-win for any business. This idea broadens the thought process where the aspiration of employee and business needs can be married together in the ambit of an agile role, which is mostly missed or not given priority. Excelling in this approach would enable businesses to provide hands-on learning opportunities to employees, making teams efficient, projects predictable, and employees motivated. This journey results in happy employees, leading to happy customers, who are like two sides of a coin, where companies can’t ignore either of them.

Welcome to 2025! As we enter this new year, it's the perfect time to expand your software architecture skills. Software architecture is a critical skill for developers, not just for those who aspire to become architects. Understanding the principles and practices of software architecture empowers developers to design scalable, maintainable, and adaptable systems. Learning software architecture is not just about taking on the title of architect; it's about enhancing your ability to make informed decisions that influence the success of a project. Since software architecture and design are deeply intertwined, changes in one often impact the other. By mastering architecture, you'll be better equipped to adapt to these changes, making you a more effective and valuable developer. Moreover, investing in architectural knowledge can significantly boost your career by preparing you for leadership roles and complex technical challenges. In this article, I'll recommend five excellent books that can help deepen your understanding of software architecture, improve your expertise as a software architect, or enhance your overall knowledge. 1. Head First Software Architecture: A Learner's Guide to Architectural Thinking This book became my favorite in 2024, and for good reason. It clearly explains how software architecture differs from software design. One key insight into software design can impact software architecture and vice versa. This book is a must-read if you're looking for an engaging, beginner-friendly introduction to architectural thinking. Its interactive approach and practical examples make it an excellent starting point. Link: Head First Software Architecture: A Learner's Guide to Architectural Thinking 2. Fundamentals of Software Architecture: An Engineering Approach This classic book introduces two foundational laws of software architecture: The "why" is more important than the "how."Everything involves trade-offs. The authors delve into various architectural styles, trade-offs, and decision-making processes, offering a comprehensive overview of software architecture. This book is a great first or second read, especially for those looking to master the terminology and explore diverse architectural approaches. Link: Fundamentals of Software Architecture: An Engineering Approach 3. Building Evolutionary Architectures: Automated Software Governance (2nd Edition) One key reality of software development is change. Business requirements evolve, and so must software architecture. This book emphasizes designing architectures that adapt to changes and discusses software erosion — how systems degrade over time without proper care. This book is invaluable if you want to build systems ready for change. It's a fantastic guide to creating evolutionary architectures. Link: Building Evolutionary Architectures: Automated Software Governance 4. Just Enough Software Architecture: A Risk-Driven Approach This practical guide highlights the importance of balancing simplicity and complexity in software architecture. It introduces using constraints as guidelines to achieve desired outcomes while demonstrating how small changes can significantly impact system properties. If you're seeking a straightforward, pragmatic approach to architecture, this book is an excellent choice. Link: Just Enough Software Architecture: A Risk-Driven Approach 5. Facilitating Software Architecture: Empowering Teams to Make Architectural Decisions Software architecture is rarely the responsibility of a single person. Collaboration is key to creating successful architectures. This book focuses on decentralized architecture models, emphasizing the importance of teamwork and shared decision-making. It also explores tools like the C4 model and tech radar to guide teams in maintaining architectural alignment and readiness for change. Thus, this book is perfect for those who want to foster collaborative architectural practices within their teams. Link: Facilitating Software Architecture: Empowering Teams to Make Architectural Decisions A Note on Clean Code and Clean Architecture Many people wonder about the popular book Clean Code and its follow-up, Clean Architecture. While these are excellent resources, I don't recommend starting with them. Clean Code, for instance, lacks sufficient focus on software architecture, and I've seen developers struggle by trying to apply its principles universally, such as forcing a hexagonal model into every project. Once you've completed the five books mentioned above, you can explore Clean Architecture for additional insights. However, avoid treating it as a one-size-fits-all solution. Software architecture has no silver bullet — every system has unique requirements and trade-offs. These five books will provide you with a solid foundation in software architecture. These resources offer valuable perspectives and practical guidance, whether you are just starting or looking to enhance your skills. Happy reading, and may 2025 be a year of growth and success in your software architecture journey! Video

By Otavio Santana CORE

The world of software engineering is on the cusp of a transformation, driven largely by the rapid advancement of Generative AI (GenAI). The AWS CEO recently suggested that developers might stop coding within two years as AI takes over coding tasks. Is this an accurate prediction? Will GenAI really force coders to abandon their careers? The answer isn't straightforward. GenAI will no doubt automate many coding jobs, which will cut down the need for some positions. However, it won't make software engineers a thing of the past. It's similar to how automation changed fields like manufacturing. GenAI will cause a shift, but not a total replacement. We'll still need software engineers — though in a more advanced and specialized way. They'll focus on jobs that AI can't handle by itself. AI Hallucinations and Human Oversight One of the clearest indicators that software engineers are here to stay is the persistence of AI hallucinations — instances where AI systems produce incorrect or nonsensical outputs. Such mistakes show where AI falls short especially when it needs to grasp things, make tricky choices, or understand the bigger picture. Even as AI gets better, it still messes up, often failing to be as reliable as we need in critical situations. People who engineer software have a key job in identifying, reducing, and fixing these errors. As AI becomes a bigger part of our world, we'll need more humans to keep an eye on AI-run systems. Engineers will need to steer AI systems, handle their weak spots, and make sure they're used ethically. Can Hallucination-Prone AI Be Trusted? Even though GenAI shows promise, we can't let AI-generated software or choices run crucial systems. AI mistakes could cause disasters in high-risk settings where we need things to work all the time. This is why we can't do without human engineers. Software engineers have to put in place safety measures like automatic testing, code checks, and backup plans to make sure AI-generated code is reliable. While AI can help write code, humans still need to check, test, and keep an eye on things. In fields where safety and security are must-haves, it would be careless to use AI-driven systems without humans watching over them. The Role of Software Engineers in the AI Era While AI will certainly reduce some traditional coding tasks, including boilerplate code and debugging, it will also open up new opportunities for software engineers to engage in more meaningful, higher-level tasks. Some areas where engineers will have success in the AI era include: AI integration: Engineers will integrate AI into business processes, develop AI models, and make sure AI has ethical usage.AI oversight: As AI does more tasks, engineers will need to watch over AI systems making sure they're secure, reliable, and accurate.System architecture: Engineers will create the structures that include AI technologies making sure they can grow and perform well.Cybersecurity: With AI systems leading the way, the need for cybersecurity experts to protect these systems will grow.Innovation: Free from doing the same coding tasks over and over, engineers can solve problems and push technology to new limits. Way Forward While GenAI has an impact on the software engineering field, it doesn't mean the end of coding or the need to code. Rather, it points to a change toward more advanced jobs where engineers will team up with AI focusing on watching over, coming up with new ideas, and bringing things together. Coders who keep up with these shifts and learn new skills won't end up jobless — they'll be more sought after than ever, helping shape a future where AI and human smarts work side by side. In this new time, software engineers won't vanish — they'll grow and change.

TL; DR: Unfinished Action Items: How to Make Retrospectives Useful If your team consistently creates action items during Retrospectives but rarely completes them, you’re not alone. Unfinished action items are a major productivity killer and lead to stalled progress. This article highlights five actionable practices to ensure Retrospective tasks get done, including limiting action items in progress, assigning clear ownership, and adding a reviewing progress in every Retrospective. The key to real improvement isn’t in creating long lists — it’s in following through. By treating Retrospective action items with the same importance as other Sprint tasks, your team can finally break the cycle of unfinished improvements and see real, beneficial change, individually and at the team level. The Problem With Unfinished Action Items How often have you left a Retrospective feeling like you’ve cracked the code, only to realize two Sprints later that nothing has changed? We’ve all been there. Teams are great at creating action items, but things tend to fall apart when it comes to following through. It’s not enough to just make lists of improvements — we need actually to implement them. One of Scrum’s first principles is continuous improvement, derived from Lean’s Kaizen philosophy. Kaizen focuses on small, incremental changes that compound, driving long-term progress. Scrum incorporates this through Retrospectives, where teams identify areas for improvement after each Sprint. However, Kaizen only works when improvements are implemented. Unfinished action items break the cycle, leaving issues unresolved and stalling growth. Unfinished action items are one of Scrum teams’ biggest productivity and improvement killers. Without follow-up, improvements remain theoretical. The accumulation of unfinished items leads to repeat issues and disengagement from the Retrospective process. The True Purpose of a Retrospective: Why Action Items Are Still Essential Many Scrum teams recognize the value of Retrospectives beyond just generating action items. They focus, for example, on team alignment or improving psychological safety, which are all vital elements of an effective team. However, without agreeing on improvements, these activities may prove superficial: Team alignment ensures everyone is working cohesively toward the same goals. But alignment without concrete actions won’t result in real, tangible improvements.Psychological safety promotes trust, but discussions without action can lead to complacency.Process improvement discussions are valuable, but without actionable steps, those improvements will remain theoretical.Conflict resolution helps smooth collaboration but should be followed by actions that prevent future issues.Continuous learning drives reflection but only becomes impactful when applied. So, some teams believe these benefits alone are enough to call the Retrospective a success, often neglecting the crucial step of creating and following through on actionable improvements. While these five elements are critical, they are not enough on their own. Action items are the glue that binds these insights together and translates them into real, continuous improvement. Teams must avoid the pitfall of thinking that a Retrospective is complete without tangible, actionable steps. How to Turn Action Items Into Completed Improvements By following a few key strategies, you can double or even triple the effectiveness of your Retrospectives. It’s not just about identifying areas for improvement but ensuring those are followed through. The following steps will help your team turn Retrospective action items into actual, impactful results: Limit the number of action items: Focus on 1–3 high-priority items per Retrospective. Too many action items overwhelm the team and lead to incomplete follow-through.Assign clear ownership and dates: Each action item needs a specific owner and a “delivery date.” Without these, tasks fall through the cracks. Ensure items are concrete and measurable, such as “Sarah will set up a weekly sync with the marketing team by Friday.” (Think of “Directly Responsible Individuals.”) Review previous action items at every Retrospective: Start every Retrospective by reviewing the status of the last Sprint’s action items. This holds the team accountable and helps identify why certain items weren’t completed and where support from the team is needed. (Inspection and adaptation work here, too.)Track action items publicly: Use a public board to track progress. Visibility drives accountability and ensures that action items don’t get forgotten.Make action items part of Sprint Planning: Incorporate action items into Sprint Planning, ensuring they are treated with the same attention as other Sprint tasks, preventing them from being sidelined. Food for Thought on Action Items Here are some additional insights to help ensure that team members complete action items, leading to continuous improvement: SMART goals for action items: Use SMART goals — Specific, Measurable, Achievable, Relevant, Time-bound — when defining Retrospective action items. Instead of saying “improve communication,” try “Set up a weekly check-in with the marketing team by Friday.” This ensures clarity and accountability. (Learn more about SMART and INVEST.)Continuous monitoring during the Sprint: Don’t wait until the next Retrospective to check in on action items. Dedicate, for example, a portion of your Daily Scrum sessions to quickly review progress on action items if needed, ensuring they stay top-of-mind throughout the Sprint.Balance between process and product improvements: Ensure a balance between process improvements (like communication and collaboration) and product improvements (such as code quality and technical practices). Focusing too much on one over the other can lead to lopsided progress.Avoid picking only low-hanging fruits: Real change results from tackling big issues that may require more than a Sprint or two to complete. Therefore, to reach your team’s full potential, avoid focusing solely on small improvements to keep your action item list short and tidy.Celebrate wins: When action items are completed and result in improvements, recognize and celebrate these wins. This acknowledgment reinforces the value of the Retrospective and motivates the team to take future action items seriously.Be mindful of organizational culture: Company culture has a significant impact on how action items are handled. If the organizational structure is too hierarchical or top-down, teams might feel powerless to implement change. Building a culture of autonomy and support for Scrum teams is, therefore, essential. Conclusion: The Key to Continuous Improvement Is Follow-Through Unfinished action items undermine continuous improvement. While identifying areas for growth in a Retrospective is important, implementation is where progress happens. The Kaizen principle teaches us that meaningful change comes from small, consistent improvements, but only when the team ensures those improvements are realized. To break the cycle of unfinished action items, focus on completing fewer, higher-impact actions. By following the five steps outlined here, your team can close the gap between planning and execution, and transform Retrospectives into a tool for real, measurable change. Continuous improvement isn’t just a principle — it’s a process, and your team holds the key to making it work.

By Stefan Wolpers CORE

My friend was contemplating a career change, possibly into game development or software engineering. I thought hard about what advice to give. The following is my opinion, which is biased towards what I know and do. TL;DR: Head over to Kotlin’s interactive website to execute and edit code. That’s it — you’re coding. Still reading? Well, I hope you at least ran one Kotlin example. I have mostly been a backend developer using Java, but now I use Scala. I started my career writing satellite navigation software in C++ back in 2000. A couple of years later, I was in the game industry professionally, then stopped becoming a contractor in 2006, writing phone apps. Since 2009, I’ve primarily focused on backend development. I’ve done many side projects along the way, and the last time I used TypeScript was yesterday. Background An entry-level programming job in London can pay between £30,000 - £60,000. But this is just the beginning. With dedication and continuous learning, you can climb the ladder to a senior position earning around £80,000, and after a number of years, surpass the £100,000 mark. In the games industry, expect less salary and more work, and there’s a brilliant book about it: "Press Reset: Ruin and Recovery in the Video Game Industry." If you’re in the United States, you can be paid much more. Remember: the more you learn and apply, the more you can earn. It’s not just about learning, but also about doing, that can boost your potential earnings. To Get a Get Job, There Are Two Parts 1. First, You Must Get an Interview, and Standing Out Will Really Help You don’t need a university or college qualification. There are online courses such as: Coursera - Some courses are aligned with universities. In general, courses tend to be more academic. These are more of an undertaking.Udemy - Great range of courses; individuals offer them, some are great. Some are small courses.AlgoExpert - This is an excellent resource. It’s well worth a look.Create your own projects. At first, do something tiny — anything you can compile and run. Then, do something slightly bigger and repeat.Most people aim too big (I’m guilty of that); don’t overthink it. Creating something of your own is an accomplishment; do the smallest thing possible. If you create a calculator, then adding two numbers is a win! Then, if you want to implement subtraction, it’s a smaller step.After you’re proficient and the days of creating calculators are too easy, you can create something impressive to showcase on your CV.Contribute to open-source projects on GitHub. This is harder than creating your own small projects; the payoff is better.You can create an online presence. Stack Overflow is an online resource for questions and answers. If you answer questions for people, any potential employer can see this, and it’s beneficial.If you create a blog, please do something informative, such as using a new library and explaining how you got it working. Sharing this information is genuinely helpful.Don’t do something like “10 algorithms every dev should know."Use online resources. I personally love Continuous Delivery. It is very advanced; if you’re comfortable and familiar with the content, you are closer to seniority. 2.1. To Pass the Interview, You Need To Have the Knowledge You can learn almost everything online and in books. 2.2. Sometimes There’s a Coding Part: This Means You Need to Practice You can practice languages, frameworks, and technologies at home. I’ve interviewed 50+ people for roles ranging from junior to £2,000 per day. I’m both blown away at what people can achieve and paradoxically underwhelmed by their knowledge. I’m not sure how other professions work, but in development, all the above is achievable if you put the effort in. I need to expand more on a university qualification: if you have a degree, you are still very junior. As such, I start with easy questions in an interview to reflect that people still need in-depth knowledge. After university, I learned the same amount as my course in what felt like a couple weeks of my first job. University courses can focus on computer science and data structures, but you won’t use these in your career — they are mainly for job interviews. There are many more important things to learn that universities and colleges don’t teach. Million-Dollar Question: What Language Gets Things Started? Firstly, learning any language is okay. There are broadly different types of development: Frontend is a web developer and or implements a user-interface.Backend means working on a server-side solution, including everything you can’t see, like interacting with a database.Full-stack means you do both frontend and backend.Application means developing an application rather than a website. It could be Windows, MacOS, Android, iPhone, etc.Games are developed for Windows, MacOS, Android, iPhone, etc. My Recommendations Kotlin can be used for all of the above. It’s the one I would recommend the most. It’s easy to learn and has a great future.Go is picking up popularity.Java is what I primarily do; there will always be work out there. Kotlin is better than Java, which is a rather sweeping statement.Python is many people’s favorite. It’s okay to take it slow if you’re starting out. Don’t feel pressured to learn everything at once. Remember: learning something is always better than learning nothing. So, take a deep breath, start with the basics, and build your knowledge step by step. You’ve got this. Extra Details About Development Types To be a frontend or web developer, you must learn and use JS/TypeScript/HTML/CSS with a framework like React.To be a professional games developer, you must do Unity with C# or Unreal with C++. Unity with C# is what I know and love about writing games. C# is more modern than C++. Unless you plan to write and or work with AAA games, Unity will be just fine. With C#, you can do all types of development.Unreal is the industry standard for AAA games. C++ is less versatile than C#.Unity and Unreal have the best tutorials, so you’re in luck. You’ll be able to create a small game in no time.Being a backend and or frontend developer is probably the most in demand. I can’t stress enough the importance of starting with something. Start with 10 minutes of reading or watching a good resource. You’re learning the basics and not committing to a new language or career. If you want to procrastinate, you can see some figures here; Stack Overflow - 2023: Most used programming languages among developers worldwide.Stack Overflow - 2022: Most loved dreaded and wanted programming scripting and markup languagesHacker Rank - 2024: Developer Skills Report Correction: I said any language is okay. I’d avoid PHP. It’s popular, but doesn’t have a future. Perl and Assembly will be too niche unless that’s your thing. I would recommend heading over to Kotlin Example (linked in introduction) and start learning. Then, if you want to take Kotlin to the next level check out Rock the JVM. The main thing is to avoid getting put off by academic nonsense and start using a language. An example is learning Scala: As much as I love Martin Odersky, "Programming in Scala" makes the subject too intimidating, and you get diminishing returns. You’re learning the theory behind all the ins and outs without knowing the basics.Conversely, these two are an excellent way to learn: Rock The JVM (linked in previous paragraph)Dick Wall Undemy courses With whatever you do, find something where you can program some simple things on day one. I don’t know Rust and probably won’t learn it, but I love Rust by Example because it’s such a great resource. In Hollywood, they have a saying, “Show, don’t tell." Honestly, most programming books would benefit from this. A sterling example of how to do this correctly is Head First Design Patterns. I read this for my career, as design patterns were all the rage then. It meant I could remember and implement most of the design patterns due to how well-written these books are and the formula for revisiting information. At the time, I read almost every Head First book. That's it. I hope it was helpful. Please leave a comment if you want any advice or have anything to add.

Crises are part of life. When it comes to software development, crises are not a matter of "if," but "when," so you always have to be prepared for such situations. Imagine this scenario: Everything seems to be going well with your mobile app development project. Suddenly, the senior developer has to leave the project due to force majeure, and only the junior developers are left to lead the project. The delivery deadline is very close and the client is anxious. What to do? In this post, we are going to share with you a couple of recommendations and good practices to handle a crisis in a software project and to get out of the critical situation that may arise unscathed. Strategies for Handling a Crisis in a Software Project First, Get to the Root of the Problem You can't handle a crisis without thoroughly understanding what is causing the crisis. You have to define the problem, its characteristics, the impact on users or the business, and the potential risk of an even worse situation, as pointed out in an article published on LinkedIn. They recommend that only those developers who are directly related to the problem work on the resolution, so as not to abandon all areas of the project, and, because, in addition, too many people involved can generate even more problems. Action Plan Before you take action, you should have an action plan to follow. “Your crisis management plan should detail potential risks, quality assurance measures, version control protocols, continuous integration practices, and strategies for each crisis. It is essential to address both short-term solutions, problem-solving techniques, and long-term risk mitigation”, according to a HAY blog post. Create a Crisis Response Team Evaluate the members of your development team and, depending on the problem area, create a team that has the hard and soft skills necessary to handle it in the best possible way. Prioritize Issues Not all issues in a project are equally urgent. Rank the issues or incidents in order of importance and have the development team begin to address them. Clear Communication Channels When there is a problem in a software project, a lack of communication often creates even more chaos. The development team leader must ensure that there is transparent communication both among team members and communication to the client. The status of the project must be clear to both parties. Follow Agile Practices Agile development is based on principles that focus on iterative development, which provides a faster and more flexible response to crises, as noted in a study conducted by a Russian university. “Development is divided into manageable units. The team's focus is on high-quality development and testing. Errors and failures are quickly identified and resolved; the product is delivered quickly, with a reasonable schedule and budget.” In addition, since development cycles are shorter in agile development, it is easier to accept and establish changes when they are required. Factors That Contribute to a Crisis in Software Development These factors include: Poor and deficient management of the software projectLack of adequate training of the software development teamPoor technical skills in the teamLow productivity Conclusion The key to success in software development is not avoiding problems or crises, but having the right tools to deal with them. With these strategies, you can prepare for your next project and not panic when a problem arises.

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.

Open source can go beyond philanthropy: it’s a gateway to exponential learning, expanding your professional network, and propelling your software engineering career to the next level. In this article, I’ll explain why contributing to open-source projects is an excellent investment and share how to begin making your mark in the community. Why Invest Time in Open Source? Great, you’re still here! That means you’re curious about the open-source world and how it can shape your future. Before diving into how to contribute, let’s discuss why it’s worth your time, especially since many of us begin contributing during our time. Open source isn’t just a philosophy or a community-driven mindset; it’s much more than that. It’s a vibrant, advanced software industry where powerful companies and brilliant minds converge to build, innovate, and drive progress. Open Source: A Modern Pillar of Software Engineering Open source often carries the misconception of being a volunteer-driven side hustle, but that’s far from the truth. It’s a critical element of the global software industry, embraced by tech giants and startups alike. Microsoft, once an open-source skeptic, is now a staunch advocate. IBM’s acquisition of Red Hat, the largest open-source company, for 34 billion dollars highlights the industry’s power and value. While the feel-good factor of helping others is undoubtedly there, open-source is also a sophisticated, high-demand industry. Many of today’s best practices — code reviews, automated testing, software documentation, and issue tracking — trace their origins back to the open-source world. Major organizations like Microsoft, PayPal, and Adobe have adopted inner-source practices, which essentially bring open-source methodologies inside their organizations. Some of the most significant software advancements, like databases (the most popular ones are open-source) and infrastructure tools like Kubernetes, have their roots in the open-source community. Open source connects people globally through shared methodologies, cutting-edge techniques, and a mission to build better software. Open-source components are woven into the very fabric of modern software development — making it hard to imagine the tech world without them. Six Reasons To Contribute To Open Source If you’re still wondering whether it’s worth the effort, let’s explore six compelling reasons why participating in open source can boost your career and broaden your horizons: 1. Learn From the Best By diving into open-source projects, you gain access to some of the most skilled engineers in the world. Experts from companies like IBM, Google, Red Hat, and more will review your code. It’s an incredible opportunity to learn directly from leaders in the tech industry. 2. Expand Your Experience Contributing to open source provides unique experiences, allowing you to collaborate on global, distributed projects that impact the world. Whether you’re an entry-level developer seeking growth or a senior engineer honing your skills, open source offers unparalleled learning opportunities. 3. Grow Your Network Working on open-source projects connects you with professionals from diverse backgrounds and organizations. These connections can lead to new job opportunities, collaborative ventures, or even the creation of your own company. 4. Boost Communication Skills Open-source work requires more than just coding — it demands effective communication. Engaging with the community, defending proposals, and leading discussions help refine your soft skills. It is especially relevant if you’re aiming for leadership roles like Staff Engineer or Principal Engineer, where influence and communication are key. 5. Improve Language Skills Open-source projects provide non-native English speakers an excellent opportunity to practice and improve their English skills. Moreover, contributing internationally exposes you to other languages, helping you bridge communication gaps and break the ice in global interactions. Personally, open-source has allowed me to improve my English, French, Italian, and Spanish. 6. Stand Out Professionally The best job offers often come not from searching but from being sought after. Contributing to open-source makes you a part of a minor, elite group of engineers. Out of the millions of Java developers, how many are core contributors to the Java platform itself? That number is minimal, giving you an edge in the industry. In summary, contributing to open source enhances your influence as a software engineer, gives you access to unique opportunities, and helps you realize that code is just a part of the bigger picture. How To Start Contributing Contributing to open source takes time, especially if you aim to become a committer. It takes discipline, patience, and a willingness to learn constantly. But the good news is, it’s achievable. Here are some steps to help you get started: 1. Choose a Project You’re Passionate About The first step is finding a project that excites you, whether it’s something you use at work, want to learn more about or enjoy. Open-source contributions require long-term commitment, so pick a project you won’t mind spending time on regularly. 2. Introduce Yourself Once you’ve chosen a project, join the community through mailing lists, Slack, Discord, or other platforms. Introduce yourself and express your interest in helping. 3. Observe Before diving in, take the time to understand the project’s workflow. Watch how PRs are handled, read through the comments, and familiarize yourself with the code style and community dynamics. 4. Read the Documentation The documentation provides a window into the minds of the engineers who built the project. Reading it will help you understand the project profoundly and inspire you to contribute by improving the docs, especially if you notice areas that need clarification. 5. Be a Steward, Not Just a Contributor Adding new features is exciting, but maintaining and improving existing code is just as important. Embrace your role as a project steward and focus on reducing complexity rather than adding unnecessary functionality. 6. Take on the Unloved Tasks Every project has tasks nobody wants to do, such as updating documentation, adding tests, or cleaning up old code. These contributions are invaluable and great for getting your foot in the door. 7. Contribute Beyond Code Not all contributions are code-related. You can help with tutorials, articles, workshops, or even handle social media. Open-source is more than just writing code — it’s about building a community. Recommended Projects To Start With If you’re unsure where to start, consider contributing to one of these projects: Jakarta EEMicroProfileJakarta DataJakarta NoSQLMicroStream These are just a few projects I’m personally involved with, and I’d be happy to guide you along the way. If you have any questions, don’t hesitate to reach out! Conclusion Open source is a game-changer — not only in terms of technology but also in the opportunities it creates. It has transformed my life, allowing me to travel the world, meet incredible people, and build long-lasting friendships. The open-source community has become like family, from RV trips across the US to parachuting adventures and museum visits. Open source can do the same for you. It’s more than just code; it’s about building connections, mastering new skills, and making an impact far beyond your desk. If you’re nearby or at any open-source event, let me know! I’d love to meet up and share experiences.

By Otavio Santana CORE

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