Team Management Resources

DZone's Featured Team Management Resources

Explore the Story Point Estimation and Story Splitting Relationship

By Liam Do

Agile project management is all about breaking down complex tasks into manageable pieces and accurately estimating their effort. Two key techniques in this process are story point estimation and story splitting. Understanding how these two practices intersect can significantly boost your team's productivity and project outcomes. Let's look into the relationship between story point estimation and story splitting and demonstrate how your Agile workflows can benefit from both. What Is Story Point Estimation? A fundamental concept in Agile project management is story point estimation. It is a technique for estimating the amount of work, complexity, and risk involved in finishing a user story. Instead of using hours or days, teams use story points to maintain a relative sizing approach. So, why story point? They help teams focus on the effort rather than the time it might take to complete a task. This method accounts for uncertainties and variations in productivity, making it more adaptable to different scenarios. How Do Story Points Work? Teams assign a numerical value to each user story. These values are often based on the Fibonacci sequence (1, 2, 3, 5, 8, 13, etc.) or the T-shirt sizes, which reflects the idea that larger numbers or sizes should represent exponentially more effort. Here's a quick breakdown: Fibonacci Sequence T-Shirt Sizes Details 1 point XS A very simple task with minimal complexity 2-3 points S Slightly more complex tasks but still manageable within a short period 5-8 points M Tasks that require more effort, likely involve multiple aspects and potential risks 13 points and above L and above Highly complex tasks that might need to be split into smaller, more manageable pieces The team can more efficiently plan their sprints, prioritize tasks, and spot potential bottlenecks by assigning story points. Story points give a clearer picture of the workload and help in making informed decisions about task assignments and deadlines. What Is Story Splitting? Story splitting is another essential technique in Agile project management. It's all about breaking down large, complex user stories into smaller, more manageable pieces. This practice not only makes the workload more approachable but also ensures that each piece can be completed within a single sprint. Why Split Stories You might wonder why we need to split stories at all. The main reasons include enhanced manageability, increased focus, and better alignment with sprint goals. Smaller stories are easier to track and complete, making planning and execution more straightforward. They allow teams to focus on specific tasks, leading to higher-quality outcomes and consistent value delivery. When To Split Stories Not all stories need splitting, but certain signs indicate when it might be necessary. If a story is too large to be completed within a single sprint, has multiple acceptance criteria, or if the requirements are vague, it's a good candidate for splitting. Effective methods for story splitting include dividing by workflow, business rules, or data variations. For instance, a feature requiring design, development, and testing can be split into three separate stories. Similarly, a payment system could be split into stories for credit card payments, PayPal payments, and so on. By splitting the story, the team can tackle each part step-by-step, making progress visible and manageable. How Story Point Estimation Can Help in Story Splitting Story point estimation and story splitting are like two sides of the same coin, working together to streamline Agile project management. Teams may efficiently select when and how to split stories by using story points to identify overly complicated or large stories. This ensures that each element is manageable and deliverable within a sprint. Identifying Complex Stories Story points help teams gauge the complexity and effort required for each user story. When a story receives a high point value, it's a signal that the story might be too large or complex to handle in one go. This is where story splitting comes in handy. By breaking down a high-point story, the team can transform it into smaller, more digestible pieces. Techniques for Splitting Stories Using story points to guide splitting can be quite straightforward. For example, if a story is assigned 13 points, the team can look at the tasks involved and split them based on different criteria such as workflow stages, business rules, or data variations. Imagine a project involving a new user registration feature. If this story is estimated at 13 points, the team might split it into parts like designing the registration form (2 points), implementing the front-end (3 points), creating the back-end logic (5 points), and setting up email verification (3 points). This approach breaks down the complexity and makes each task more manageable. How Story Splitting Can Help Story Point Estimation Story splitting doesn't just make tasks more manageable; it also plays a crucial role in refining story point estimation. By breaking down complex stories into smaller, clearer tasks, teams can enhance the accuracy of their estimations, leading to better planning and execution. Simplifying Estimation When stories are too large or complex, estimating their effort can be challenging and often inaccurate. Splitting these stories into smaller parts simplifies the estimation process. Each smaller story is more straightforward to understand, making it easier for the team to assign accurate story points. Improving Accuracy Smaller stories come with more specific requirements and less ambiguity. This clarity allows the team to make more precise estimations. For example, a large story like "Implement user authentication" might be vague and hard to estimate accurately. By splitting it into smaller stories such as "Design login UI," "Develop front-end login functionality," and "Set up back-end authentication," each part becomes easier to evaluate and estimate accurately. Real-World Application Let's say a team is tasked with developing a feature for generating sales reports in an application. Initially, the story might seem daunting, and estimations could range wildly. By splitting the story into smaller tasks—such as creating the report UI, implementing data fetching, and adding filtering options—the team can provide more accurate story point estimates for each part. This not only improves the reliability of the estimates but also makes the planning process smoother and more predictable. Final Words Story splitting and story point estimation work well together in Agile project management. Accurately estimating story points helps teams identify complex tasks that need to be broken down, making them manageable within a sprint. On the other hand, breaking up stories into more manageable, well-defined tasks improves the precision of story point estimates, which results in more effective planning and execution. Adopting these techniques can transform your Agile processes, making your team more efficient and your projects more predictable. More

Rookie Mistakes Scrum Masters Make

By Stefan Wolpers

CORE

TL; DR: Top Five Rookie Mistakes by Self-Proclaimed Scrum Masters Are you struggling with imposter syndrome as a new Scrum Master? Avoid five common rookie mistakes Scrum Masters make. Instead, discover how to set clear Sprint Goals, build trust, balance metrics, and empower your team to make independent decisions. Don’t let early missteps define your journey. Learn from these mistakes and transform them into stepping stones towards mastery. By understanding and addressing these pitfalls, you’ll gain confidence, enhance your leadership skills, and truly embody the principles of Scrum. This article provides actionable insights and practical exercises to help you grow from a beginner into an effective and respected Scrum Master. Rookie Mistakes Scrum Masters Make Let us delve into the rookie mistakes Scrum Masters make: 1. Ignoring the Importance of the Sprint Goal Mistake: Treating the Sprint Goal as optional or just a list of tasks, leading to a lack of focus and direction for the Scrum Team Why it’s a mistake: The team lacks a unified purpose without a clear Sprint Goal, resulting in fragmented efforts, reduced overall value delivery, and difficulty measuring success. The team may become directionless, working on tasks that don’t align with the Product Goal or the strategic objectives of the product generally. Learning opportunity: Legitimate beginners quickly realize the importance of a well-defined Sprint Goal as a beacon guiding the team’s efforts. It fosters collaboration and ensures that the team delivers meaningful value each Sprint. To practice this, try a Sprint Goal workshop before the next Sprint, where the team collaborates to draft a clear, cohesive goal. 2. Micromanaging the Team Mistake: Acting as a task or project manager, constantly overseeing and directing the work of the Developers Why it’s a mistake: Scrum Masters should serve the team by removing impediments and facilitating processes, not controlling the work as the Developers have agency doing their part. Micromanagement stifles team autonomy and innovation, leading to reduced morale and a lack of ownership among team members, ultimately hampers productivity and creativity. Learning opportunity: True beginners learn to trust their team’s capabilities, focusing instead on enabling the team to self-organize and resolve issues independently, leading to higher engagement and better problem-solving. An exercise to help with this is to restrain from solving issues during a Sprint but observe and support their teammates’ progress. 3. Neglecting To Build Team Trust and Psychological Safety Mistake: Failing to create an environment of trust and psychological safety where all team members feel comfortable sharing ideas and concerns Why it’s a mistake: Without trust and safety, team members are less likely to engage fully, collaborate effectively, or take risks. Neglecting trust stifles innovation and continuous improvement, leading to a work environment with undisclosed problems, lackluster team engagement, and restrained creativity. It can also result in high turnover and low job satisfaction. Learning opportunity: Proficient Scrum Masters actively work to build and maintain a culture of trust and psychological safety. They encourage open communication and constructive feedback. A practical exercise is to hold regular team-building activities and trust exercises, such as sharing personal success stories, challenges, and failures to build empathy and understanding among team members. 4. Focusing Solely on Metrics and Reporting Mistake: Overemphasizing metrics, OKRs, and KPIs, turning the Scrum Master role into a data-entry clerk burdened with excessive reporting Why it’s a mistake: While metrics can provide valuable insights, overemphasis can distract from the true purpose of Scrum, which is delivering value through collaborative efforts and continuous feedback based on frequent releases and an empirical process. A metrics-driven approach can also lead to gaming the system, where team members focus on meeting the metrics rather than creating genuine value, thus distorting the team’s priorities. Learning opportunity: Effective Scrum Masters balance metrics with qualitative insights, using them to support, not dictate, team decisions and progress. They understand that metrics are tools, not goals in themselves. An exercise to implement this is to periodically review the metrics with the team, discussing their relevance and how they align with actual value delivery, ensuring a balanced approach. 5. Failing To Empower the Team Mistake: Not empowering the team to make decisions and solve problems, often stepping in to make decisions or resolve conflicts Why it’s a mistake: This approach undermines the team’s confidence and ability to self-manage, leading to dependency on the Scrum Master and reduced team ownership of the work. It hampers the team’s growth, creativity, and innovation ability, as members are not encouraged to think independently or take initiative. Learning opportunity: Good Scrum Masters learn to step back and facilitate the team’s decision-making processes, encouraging team members to take ownership of their work and develop their problem-solving skills. A helpful exercise is to use a decision matrix, for example, based on the outcome of a Delegation Poker session, where the team collaboratively decides on solutions to issues without direct intervention from the Scrum Master, promoting autonomy and confidence. Useful Practices for Beginners To Avoid Rookie Mistakes Scrum Masters Make Some food for thought for the aspiring learner: there is no need for you to reinvent the wheel. Embrace Continuous Learning Scrum Masters should always be on a path of continuous learning. Scrum and agile practices evolve, and so should your understanding and application of them. Seek opportunities for training, certifications, and networking with other Scrum professionals. For example, join the Hands-on Agile Slack community or our Meetup group. Understand the Organizational Context Every organization has its unique culture and challenges. Understanding the broader context within which your team operates can help you better support and advocate for Scrum practices. Engage with stakeholders and management to align Scrum with organizational goals. Remember, you cannot change a system at the Scrum team level. Balance Empathy With Accountability Building a high-performing team requires a delicate balance of empathy and accountability. While fostering a supportive environment is crucial, holding the team accountable to commitments and quality standards is equally important. Great Scrum teams hold themselves accountable all the time; they are professionals. Be a Servant Leader As a Scrum Master, your primary role is to serve the team, for example, by removing impediments, facilitating communication, and supporting the team’s self-organization. The team’s success measures your success, so focus on empowering them. Adaptability Is Key No two teams are the same, and what works for one might not work for another. Be flexible and willing to adapt your approach based on the team’s needs and feedback. Continuously inspect and adapt not just the team’s processes but your own practices and mindset. Foster a Growth Mindset Encourage a culture where failure is seen as an opportunity to learn and grow. Coupled with a growth mindset, it can significantly enhance the team’s ability to innovate and improve continuously. Celebrate successes but also openly discuss failures and the lessons learned from them. Value Feedback Loops Feedback is the cornerstone of continuous improvement. Make sure your team regularly seeks and gives feedback, not just during formal events like Sprint Reviews and Retrospectives but also in daily interactions. Feedback taken seriously will help identify issues early and promote a culture of transparency and improvement. Conclusion The critical difference between the rookie mistakes of the ignorant imposter and the actions of a learning beginner is the willingness to reflect, adapt, and grow from experiences. Self-proclaimed experts who misunderstand and, consequently, misapply the principles of Scrum fail to recognize and rectify their mistakes. At the same time, true beginners use these early missteps as stepping stones toward becoming effective and respected Scrum Masters. More

Deep Work for Site Reliability Engineers

By Krishna Vinnakota

Workflow, From Stateless to Stateful

By Nicolas Fränkel

CORE

Conflict Management in Technology Teams: Insights From Google's Project Aristotle

By Arun Pandey

CORE

Creating Value With Scrum

TL; DR: Scrum Master Interview Questions on Creating Value With Scrum If you are looking to fill a position for a Scrum Master (or agile coach) in your organization, you may find the following 12th set of the Scrum Master interview questions useful to identify the right candidate. They are derived from my eighteen years of practical experience with XP as well as Scrum, serving both as Product Owner and Scrum Master as well as interviewing dozens of Scrum Master candidates on behalf of my clients. So far, this Scrum Master interview guide has been downloaded more than 27,000 times. Scrum Master Interview Questions: How We Organized Questions and Answers Scrum has proven time and again to be the most popular framework for software development. Given that software is eating the world, a seasoned Scrum Master is even nowadays, given the frosty economic climate of Spring 2024, in high demand. And that demand causes the market entry of new professionals from other project management branches, probably believing that reading one or two Scrum books will be sufficient, which makes any Scrum Master interview a challenging task. The Scrum Master Interview Questions ebook provides both questions as well as guidance on the range of suitable answers. These should allow an interviewer to dive deep into a candidate’s understanding of Scrum and her agile mindset. However, please note: The answers reflect the personal experience of the authors and may not be valid for every organization: what works for organization A may not work in organization B. There are no suitable multiple-choice questions to identify a candidate’s agile mindset, given the complexity of applying “Agile” to any organization. The authors share a holistic view of agile practices: Agility covers the whole arch from product vision (our grand idea on how to improve mankind’s fate) to product discovery (what to build) plus product delivery (how to build it). Creating Value as a Scrum Master The following questions and responses are designed to draw out a nuanced understanding of a candidate’s experience and skills in applying agile product development principles to improve customer value and economics of delivery and enhance predictability in various organizational contexts to address the current economic climate: Question 74: Resistant Industries How have you tailored Scrum practices to elevate customer value, particularly in industries resistant to Agile practices? Background: This question probes the candidate’s ability to adapt Scrum principles to sectors where Agile is not the norm, emphasizing customer-centric product development. It seeks insights into the candidate’s innovative application of Scrum to foster customer engagement and satisfaction, even in challenging environments. It is also an opportunity for the candidate to build confidence in the interview process and rapport with the interviewers. Acceptable Answer: An excellent response would detail a scenario where the candidate navigated resistance by demonstrating Agile’s benefits through small-scale pilot projects or workshops. They would probably even describe specific adjustments to Scrum events or artifacts to align with industry-specific constraints, culminating in enhanced customer feedback loops and ultimately leading to product features that directly addressed customer pain points. Question 75: Reducing Product Costs Please describe a scenario in which you significantly reduced production costs through strategic Scrum application without compromising the product’s quality. Background: This delves into the candidate’s proficiency in supporting the optimization of a team’s capacity allocation and streamlining workflows within the Scrum framework to cut costs. It’s about balancing maintaining high-quality standards and achieving cost effectiveness through Agile practices. Acceptable Answer: Look for a narrative where the candidate identifies wasteful practices or bottlenecks in the development process and implements targeted Scrum practices to address them. Examples include refining the Product Backlog to focus on high-impact features, improving cross-functional collaboration to reduce dependencies, or leveraging automated testing to speed up lead time while preserving quality standards. The answer should highlight the candidate’s analytical problem-solving approach and ability to help the team accept a cost-conscious entrepreneurial stance to solving customer problems without sacrificing quality. Question 76: Improving Predictability in a Volatile Market Please share an experience where you used Scrum to improve predictability in product delivery in a highly volatile market. Background: This question explores the candidate’s capability to use Scrum to enhance delivery predictability amidst market fluctuations. It’s about leveraging Agile’s flexibility to adapt to changing priorities while maintaining a steady pace of delivery. Acceptable Answer: The candidate should recount an instance where they utilized Scrum artifacts and events to better forecast delivery timelines in a shifting landscape. This example might involve adjusting Sprint lengths, prioritizing Product Backlog items more dynamically, or involving closer stakeholder engagement to reassess priorities during Sprint Reviews or other alignment-creating opportunities, for example, User Story Mapping sessions. The story should underscore their strategic thinking in balancing flexibility with predictability and their communication skills in setting realistic expectations with stakeholders. Question 77: Successfully Promoting Scrum Despite Skepticism How have you promoted the value of Scrum in organizations where the leadership and middle management met Agile practices with skepticism? Background: This question examines the candidate’s ability to champion Scrum in environments resistant to change. Such an environment requires a deep understanding of Agile principles and strong advocacy and education skills. Acceptable Answer: Successful candidates will describe a multifaceted strategy that includes educating leadership on Agile benefits, organizing interactive workshops to demystify Scrum practices, and securing quick wins to demonstrate value. They might also discuss establishing a community of practice to sustain Agile learning and sharing success stories to build momentum. The answer should reflect their perseverance, persuasive communication, and their role as a change agent. (Learn more about successful stakeholder communication tactics during transformations here.) Question 78: Effective Change Please describe your approach to conducting effective Sprint Retrospectives that drive continuous improvement. Background: The question probes the candidate’s techniques for facilitating Retrospectives that genuinely contribute to team growth and product enhancement. It seeks to understand how they ensure these events are productive, inclusive, and actionable. Acceptable Answer: A comprehensive response would outline a structured approach to Retrospectives, including preparation, facilitation, follow-up practices, and valuable enhancements to the framework, for example, embracing the idea of a directly responsible individual to drive change the team considers beneficial. The candidate might mention using a variety of formats to keep the sessions engaging, techniques to ensure all team members contribute, and strategies for prioritizing action items. They should emphasize their method for tracking improvements over time to ensure accountability and demonstrate the Retrospective’s impact on the team’s performance and morale. Again, this question allows the candidates to distinguish themselves in the core competence of any Scrum Master. Question 79: Balancing Demands with Principles Please explain how you’ve balanced stakeholder demands with Agile principles to help the Scrum team prioritize work effectively. Background: This question seeks insights into the candidate’s ability to support the Scrum team in general and the Product Owner in particular in navigating competing demands, aligning stakeholder expectations with Agile principles to focus the team’s efforts on the most impactful work from the customers’ perception and the organization’s perspective. Acceptable Answer: The candidate should provide an example of supporting the Product Owner by employing prioritization techniques, such as User Story Mapping, in collaboration with stakeholders to align on priorities that offer the most value, leading to the creation of valuable Product Goals and roadmaps in the process. They should highlight their negotiation skills, ability to facilitate consensus, and adeptness at transparent communication to manage expectations and maintain a sustainable pace for the team. Question 80: Boring Projects and Motivation How do you sustain team motivation and engagement in long-term projects with high levels of task repetition? Background: This question explores the candidate’s strategies for keeping the team engaged and motivated through the monotony of prolonged projects or repetitive tasks. While we all like to work on cutting-edge technology all the time, everyday operations often comprise work that we consider less glamorous yet grudgingly accept as valuable, too. The question gauges a candidate’s ability to uphold enthusiasm and maintain high performance in a potentially less motivating environment. Acceptable Answer: Expect the candidate to discuss innovative approaches like introducing gamification elements to mundane tasks, rotating roles within the team to provide fresh challenges, and setting up regular skill-enhancement workshops. They might also mention the importance of celebrating small wins, giving recognition, for example, Kudo cards, and ensuring that the team’s work aligns with individual growth goals. The response should underline their commitment to maintaining a positive and stimulating work environment, even under challenging circumstances. Question 81: Onboarding New Team Members Please describe your experience integrating a new team member into an established Scrum team, ensuring a seamless transition and maintaining team productivity. Background: This question assesses the candidate’s approach to onboarding new team members to minimize disruption and maximize integration speed. This approach is critical for maintaining an existing team’s cohesive and productive dynamics, acknowledging that Scrum teams will regularly change composition. Acceptable Answer: Look for answers detailing a structured and inclusive onboarding plan that includes, for example: Mentorship programs A buddy system Clear documentation of team norms and expectations, such as a working agreement and a Definition of Done Team activities Gradual immersion into the Scrum team’s projects through pair programming or shadowing The candidate should highlight the importance of fostering an inclusive team culture that welcomes questions and supports new members in their learning journey, ensuring they feel valued and part of the team from day one. Question 82: Conflict Resolution How do you approach conflict resolution within a Scrum team or between the team and stakeholders to ensure continued progress and collaboration? Background: Conflicts are inevitable in any team dynamic. This question probes the candidate’s skills in navigating and resolving disagreements in a way that strengthens the team and stakeholder relationships rather than undermining them. Acceptable Answer: The candidate should describe their ability to act as a neutral mediator, actively listen to understand all perspectives, and facilitate problem-solving sessions focusing on interests rather than positions. They might also discuss creating forums for open dialogue, such as conflict-themed Retrospectives, and the importance of fostering a culture of trust and psychological safety where conflicts can be aired constructively. The response should convey their adeptness at turning conflicts into opportunities for growth and deeper understanding. However, the candidate should also make clear that not all disputes among team members may be solvable and that, once all team-based options have been exhausted, the Scrum Master needs to ask for management support to bring the conflict to a conclusion. Question 83: Scaling Scrum? Please reflect on a time when scaling Scrum across multiple teams presented significant challenges. How did you address these challenges to ensure the organization’s success with its Agile transformation? Background: Scaling Agile practices is a complex endeavor that can highlight organizational impediments and resistance. This question delves into the candidate’s experience in successfully scaling Scrum, ensuring alignment and cohesion among multiple teams, and helping everyone see the value in a transformation. Acceptable Answer: This open question allows candidates to address their familiarity with frameworks like LeSS or Nexus or share their opinion on whether SAFe is useful. Moreover, at a philosophical level, it opens the discussion of whether “Agile” is scalable at all, given that most scaling frameworks apply more processes to the issue. Also, the objecting opinion points to the need to descale the organization by empowering those closest to the problems to decide within the given constraints and governance rules. The candidate should emphasize the importance of maintaining a shared vision and goals, creating communities of practice to share knowledge and best practices, and addressing cultural barriers to change. They should also reflect on the importance of executive sponsorship, the strategic engagement of key stakeholders to champion and support the scaling effort, and the necessity of a failure culture. How To Use The Scrum Master Interview Questions Scrum has always been a hands-on business, and to be successful in this, a candidate needs to have a passion for getting her hands dirty. While the basic rules are trivial, getting a group of individuals with different backgrounds, levels of engagement, and personal agendas to form and perform as a team is a complex task. (As always, you might say, when humans and communication are involved.) Moreover, the larger the organization is, the more management levels there are, the more likely failure is lurking around the corner. The questions are not necessarily suited to turning an inexperienced interviewer into an agile expert. But in the hands of a seasoned practitioner, they can help determine what candidate has worked in the agile trenches in the past.

By Stefan Wolpers

CORE

Sunsetting Success: How to Strategically Phase Out Products in the Digital Age

In today's rapid product landscape, innovation occurs at lightning speed. Product Managers are in perpetual pursuit of innovation, launching products, seizing new markets, and fueling growth. Building something innovative that can transform a customer’s journey, enhance their daily lives, boost productivity, or provide entertainment is exhilarating. However, what happens when the job is not as glamorous or thrilling, such as phasing out a product? How do you inspire your team to embrace the mission of gracefully retiring the product? The decision to discontinue a product is a crucial one, and when handled with care, it can preserve customer relationships, minimize disruption, and ensure a smooth transition. In this comprehensive guide, we'll explore the key steps and considerations for product managers when it's time to say goodbye to a product. The Need for Sunsetting Sunsetting a product, which refers to the process of phasing out or discontinuing a product or service, is often a necessary decision for several reasons: Technological advancements: As technology evolves, older products may become obsolete. Sunsetting allows a company to focus on newer, more advanced offerings that better meet current market demands. Resource allocation: Maintaining and supporting aging products can be resource-intensive. By discontinuing them, a company can reallocate resources—like time, money, and people — to newer and more innovative initiatives that meet the current market demand. Market changes: Consumer preferences and market trends can shift rapidly. Sunsetting a product that no longer aligns with these trends ensures that a company remains relevant and competitive. Quality and reputation: Older products that are no longer up to current standards can harm a company's reputation. Sunsetting such products can help maintain a brand's image for quality and innovation. Cost efficiency: As products age, they may become more expensive to maintain and support, especially if they require unique or outdated technology. Sunsetting can be a cost-effective decision. Regulatory compliance: New regulations or changes in compliance standards can render some products non-compliant. Sunsetting is a necessary step to adhere to these legal requirements. Strategic focus: Companies often refine their strategic direction to meet the needs of customers and stay ahead of their competitors. Sunsetting products that don't align with the new strategic goals allows a business to stay focused and efficient. User experience: Phasing out older products can also be a part of enhancing the overall user experience, pushing customers towards better, more efficient, and feature-rich alternatives. When executed well, sunsetting enables companies to reallocate resources to more promising areas, enhancing their competitiveness and capacity for innovation. This decision, while difficult, is pivotal for maintaining a robust, relevant product portfolio aligned with long-term organizational goals. Overall, sunsetting a product is a strategic move to optimize a company's portfolio, ensuring it stays innovative, relevant, and financially sound. Key Considerations for Product Managers When Sunsetting a Product 1. Impact Assessment Impact assessment, which is a critical first step, involves a thorough evaluation of sunsetting's potential consequences. One would need to analyze how sunsetting affects current users, revenue streams, and the company's brand reputation. While sunsetting a product, one must consider both short-term and long-term impacts on customer trust and the company's market position. This assessment forms the foundation for making an informed decision. 2. Sunsetting Timeline Crafting a detailed and realistic timeline is vital for a smooth transition. This timeline should cover all phases of sunsetting: initial planning, stakeholder notification, support period, and final closure. It's crucial to provide adequate time for customers and internal teams to adapt, and to anticipate potential delays or issues. 3. Stakeholder Communication and Transparency Clear, timely, and empathetic communication with stakeholders is key to managing expectations and maintaining trust. Transparency about the reasons for sunsetting, its benefits, and its impacts is essential in managing the narrative and reducing backlash. Regular updates can keep stakeholders informed and engaged throughout the process. 4. Data-Driven Decision-Making Sunsetting decisions should be rooted in solid data analysis. Examine customer engagement metrics, support requests, financial performance, and market trends. This data-driven approach helps understand the product's actual usage and viability, providing a rational basis for decision-making and supporting internal and external communication. 5. Customer Transition Planning Developing a comprehensive plan for customer transition is critical. This includes offering alternatives or upgrades, migration assistance, and robust customer support during the transition. Effective communication of these plans minimizes customer inconvenience and dissatisfaction, bolstering customer loyalty and relationships. 6. Resource Allocation Strategically reallocating resources, both human and financial, is a key aspect of sunsetting a product. Consider how to best invest these resources—whether in developing new products, enhancing existing ones, or exploring new market opportunities. This can transform the sunsetting of one product into a growth opportunity for other areas. 7. Legal and Regulatory Compliance Ensuring legal and regulatory compliance is paramount when sunsetting a product. This includes honoring existing contracts and agreements, managing data privacy concerns, and adhering to industry-specific regulations during the sunsetting process. Communicating legal implications to stakeholders, particularly regarding data handling and service commitments, is also vital. Case Study: Sunsetting at Amazon Take Amazon for an example. Known for its innovation, Amazon has occasionally sunsetted products as part of its strategic approach. One notable example is the Amazon Dash, a Wi-Fi device for repeat purchases. Despite being a technological advancement, the Dash faced regulatory challenges, especially in the EU, and was ultimately discontinued. Taking the key considerations listed in the previous sections and reflecting on how Amazon applied them to the discontinuation of its Dash product: 1. Customer and Market Impact Amazon evaluated Dash's market performance and regulatory challenges, particularly in Germany, which impacted longer-term viability and survival of the product. 2. Financial Considerations The cost of maintaining the Dash, given regulatory issues and the emergence of alternative technologies (like Echo), likely influenced its sunset. 3. Communication Strategy Amazon's shift from Dash to other products would have involved strategic communication through marketing channels, customer support channels, and sales channels to minimize customer disruption. Amazon would have also had to involve its legal team with any kind of legal and privacy challenges in terms of customer data. 4. Marketing and Customer Touchpoints Transitioning customers from Dash to other Amazon services like Echo would have been a key focus, ensuring a smooth shift in consumer behavior. 5. Financial Strategies and Incentives Phasing out Dash possibly involved financial considerations like the cost-benefit analysis of maintaining the product versus investing in more advanced technologies. In essence, Amazon's decision to sunset Dash was likely driven by a combination of market dynamics, regulatory challenges, strategic realignment towards more advanced technology, and a focus on long-term profitability over short-term gains. The company's emphasis on “Ownership” where leaders focus on longer-term value instead of short-term results often guides these decisions. This approach reflects Amazon's broader strategy of spreading investments across various sectors and leveraging technology for competitive advantage. Conclusion Sunsetting a product is a complex, yet strategic process, essential for aligning resources with market needs and organizational goals. It encompasses thorough impact assessment, detailed planning, transparent communication, data-driven decision-making, careful customer transition, wise resource allocation, and legal compliance. Though challenging, it's a vital part of the product lifecycle that, when managed thoughtfully, leads to innovation, growth, and a more focused product portfolio. For product managers, mastering the art of sunsetting is not just about ending a product's journey; it's about transforming challenges into opportunities for future success.

By Balaji Ananthanpillai

The Intersection of Executive Engineering and Staff Engineering: A Staff Engineer's Viewpoint

Executive engineers are crucial in directing a technology-driven organization’s strategic direction and technological innovation. As a staff engineer, it is essential to understand the significance of executive engineering. It goes beyond recognizing the hierarchy within an engineering department to appreciating the profound impact these roles have on individual contributors’ day-to-day technical work and long-term career development. Staff engineers are deep technical experts who focus on solving complex technical challenges and defining architectural pathways for projects. However, their success is closely linked to the broader engineering strategy set by the executive team. This strategy determines staff engineers' priorities, technologies, and methodologies. Therefore, aligning executive decisions and technical implementation is essential for the engineering team to function effectively and efficiently. Executive engineers, such as Chief Technology Officers (CTOs) and Vice Presidents (VPs) of Engineering, extend beyond mere technical oversight; they embody the bridge between cutting-edge engineering practices and business outcomes. They are tasked with anticipating technological trends and aligning them with the business’s needs and market demands. In doing so, they ensure that the engineering teams are not just functional but are proactive agents of innovation and growth. For staff engineers, the strategies and decisions made at the executive level deeply influence their work environment, the tools they use, the scope of their projects, and their approach to innovation. Thus, understanding and engaging with executive engineering is essential for staff engineers who aspire to contribute significantly to their organizations and potentially advance into leadership roles. In this dynamic, the relationship between staff and executive engineers becomes a critical axis around which much of the company’s success revolves. This introduction aims to explore why executive engineering is vital from the staff engineer’s perspective and how it shapes an organization's technological and operational landscape. Hierarchal Structure of Engineering Roles In the hierarchical structure of engineering roles, understanding each position’s unique responsibilities and contributions—staff engineer, engineering manager, and engineering executive—is crucial for effective career progression and organizational success. Staff Engineers are primarily responsible for high-level technical problem-solving and creating architectural blueprints. They guide projects technically but usually only indirectly manage people. Engineering Managers oversee teams, focusing on managing personnel and ensuring that projects align with the organizational goals. They act as the bridge between the technical team and the broader business objectives. Engineering Executives, such as CTOs or VPs of Engineering, shape the strategic vision of the technology department and ensure its alignment with the company’s overarching goals. They are responsible for high-level decisions about the direction of technology and infrastructure, often dealing with cross-departmental coordination and external business concerns. The connection between a staff engineer and an engineering executive is pivotal in crafting and executing an effective strategy. While executives set the strategic direction, staff engineers are instrumental in grounding this strategy with their deep technical expertise and practical insights. This collaboration ensures that the strategic initiatives are visionary and technically feasible, enabling the organization to innovate while maintaining robust operational standards. The Engineering Executive’s Primer: Impactful Technical Leadership Will Larson’s book, The Engineering Executive’s Primer: Impactful Technical Leadership, is an essential guide for those aspiring to or currently in engineering leadership roles. With his extensive experience as a CTO, Larson offers a roadmap from securing an executive position to mastering the complexities of technical and strategic leadership in engineering. Key Insights From the Book Transitioning to Leadership Larson discusses the nuances of obtaining an engineering executive role, from negotiation to the critical first steps post-hire. This guidance is vital for engineers transitioning from technical to executive positions, helping them avoid common pitfalls. Strategic Planning and Communication The book outlines how to run engineering planning processes and maintain clear organizational communication effectively. These skills are essential for aligning various engineering activities with company goals and facilitating inter-departmental collaboration. Operational Excellence Larson delves into managing crucial meetings, performance management systems, and new engineers’ strategic hiring and onboarding. These processes are fundamental to maintaining a productive engineering team and fostering a high-performance culture. Personal Management Understanding the importance of managing one’s priorities and energy is another book focus, which is often overlooked in technical fields. Larson provides strategies for staying effective and resilient in the face of challenges. Navigational Tools for Executive Challenges From mergers and acquisitions to interacting with CEOs and peer executives, the book provides insights into the broader corporate interactions an engineering executive will navigate. Conclusion The engineering executive’s role is pivotal in setting a vision that integrates with the organization’s strategic objectives. Still, the symbiotic relationship with staff engineers brings this vision to fruition. Larson’s The Engineering Executive’s Primer is an invaluable resource for engineers at all levels, especially those aiming to bridge the gap between deep technical expertise and impactful leadership. Through this primer, engineering leaders can learn to manage, inspire, and drive technological innovation within their companies.

By Otavio Santana

CORE

6 Agile Games to Enhance Team Building and Creativity

Joining the Agile framework provides access to resources and support that can help your organization maximize the benefits of Agile. It also provides a platform to connect with other Agile practitioners to share best practices and learn from each other. Practicing Agile working methods allows teams to pursue their goals at their own pace and with as much creativity as they want, and they're also a great way to bond as a team. Agile teams are also better able to respond to changes in the market quickly and efficiently, which is essential for success. Agile teams also tend to be more motivated, as they feel they are in control of their destiny. So, if you are wondering how to encourage your team to embrace Agile values and principles, Agile games are one of the best options to get started with. What Are Agile Games? A major benefit of Agile games is that they support team building through new learning activities and iteration. As a result, Agile games support the communication and self-organization capabilities of DevOps teams. As a result, your team members will be better able to learn Agile software more rapidly. This will lead to better collaboration between teams, more efficient development, and faster time to market. Agile games also help teams to identify potential risks and issues early in the development process. This allows them to quickly adjust and course-correct as needed. Agile games also help teams build trust, foster collaboration and encourage creativity. This in turn leads to better problem-solving, increased team morale, and a greater sense of ownership. What Agile Games Are Best for Team Building? Here you can find some of the best Agile games that help boost team effort and support. Murder Mystery Play murder mystery games to boost team communication and thinking skills. Participants need to work together to solve the case and uncover the murderer. The game encourages collaboration and creativity as players need to think outside the box and come up with unique solutions. It also tests participants' problem-solving skills and their ability to think critically. The Paper Airplane Another great Agile game is the paper airplane game, and it can be played by any team. As a basic premise, each member of your team must construct a paper airplane. The catch is that each member is only permitted to fold the plane one time before handing it over to the next member. In addition to increasing team bonding, this is an effective way to teach team members how their contributions contribute to the project as a whole. Ball Point This ball-based game follows the same principles as most Agile games, in which team members communicate and formulate strategies. The game consists of teams passing a ball around, and each time a member touches the ball, a point is scored, but points are accumulative when the last member touches the ball and is also the first one to touch it. Marshmallow Tower A marshmallow serves as the crown of a tower in this game. As simple as it may sound, the "building materials" given to teams are often fairly flimsy; spaghetti, for instance, or even string have been used as "building materials" in Agile games. This is another great Agile game for teaching teams agility since it rewards the team with the most structurally sound marshmallow tower, although speed and specifications are also important factors. Chocolate Bar A great way to get a better understanding of iterations and customer feedback for teams is through this game. It can be played in person, or with a Miro board. Your goal is simple (and delicious): you are building a chocolate bar based on customer input. One person will be designated to perform the role of the product manager or product owner, and everyone else will serve as a customer. The Emoji Game This emoji game is an excellent way to facilitate communication when it comes to Agile games. Team members must interpret what the messenger means by using emojis. The catch is that the messenger can only communicate using emojis. A favorite film or album, for example, or a message describing the messenger's characteristics might be appropriate. Conclusion These are the best Agile games for team building as they provide moral support and better communication and delivery skills. Team mates can collaborate more in a better way to solve the game and that also helps them boost These games also help increase the morale of the team and build trust between the team members. They can also help in creating better problem-solving skills and critical thinking. Lastly, these Agile games can help in breaking the monotony of the workplace and having fun while working together.

By Stylianos Kampakis

Efficient Ticket Management Using LangChain and Large Language Models

In today's dynamic business landscape, where retailers, banks, and consumer-facing applications strive for excellence and efficiency in customer support, the reliance on tools like JIRA for project management remains paramount. However, the manual creation of tickets often results in incomplete information, leading to confusion and unnecessary rework, particularly in sectors where live chatbots play a crucial role in providing real-time support to end-users. In this article, we'll explore how AI chatbots, powered by large language models, can streamline manual ticket creation. With artificial intelligence in play, businesses can reshape their project management strategies and deliver flawless customer support experiences. Solution The proposed solution will leverage ChatGPT, a large language model from OpenAI. We are going to leverage LangChain, an open-source library to facilitate the smooth integration with OpenAI. Please note that you can also leverage Llama2 models with LangChain for this use case. Figure 1: Leveraging LLM-enabled chatbot The solution components include: LangChain agents: The fundamental concept behind agents involves using a language model to decide on a sequence of actions. Unlike chains, where actions are hardcoded into the code, agents utilize a language model as a reasoning engine to ascertain which actions to execute and in what sequence. Tools: When constructing the agent, we will need to provide it with a list of tools that it can use. We will create a custom tool for Jira API. Chat memory: LangChain agents are stateless they don't remember anything about previous interactions. Since we want the AI model to collect all the relevant information from the user before creating the JIRA ticket we need the model to remember what the user provided in the previous conversation. Installing LangChain Let's first install all the dependencies: Python pip install langchain-openai langchain atlassian-python-api -U Let's set the environment variables: Python import os os.environ["JIRA_API_TOKEN"] = "<jira_api_token>" os.environ["JIRA_USERNAME"] = "<jira_username>" os.environ["JIRA_INSTANCE_URL"] = "<jira_instance_url>" os.environ["OPENAI_API_KEY"]= "<open_api_key>" Now, let's initialize the model. For this article, we will leverage OpenAI models. Python from langchain_openai import ChatOpenAI llm = ChatOpenAI(model="model-name", temperature=0) Creating Tools We will define the input schema using the Pydantic Python library. Pydantic is a data validation and settings management library in Python that is widely used for defining data models. Pydantic guarantees that input data conforms to specified models, thereby averting errors and discrepancies. It aids in generating documentation from field descriptions, thereby enhancing comprehension of data structures. Let's take a look at the schema defined using the Pydantic Python library: Python from langchain.pydantic_v1 import BaseModel, Field from typing import List, Optional, Type class TicketInputSchema(BaseModel): summary: str = Field(description="Summary of the ticket") project: str = Field(description="project name", enum=["KAN","ABC"]) description: str = Field(description="It is the description of the work performed under this ticket.") issuetype: str = Field(description="The issue type of the ticket ", enum=["Task", "Epic"]) priority: Optional(str) = Field(description="The issue type of the ticket ", enum=["Urgent", "Highest","High", "Low", "Lowest"]) Based on the code summary above, project, description, and issue type are required while priority is optional. This @tool decorator is the simplest way to define a custom tool. The decorator uses the function name as the tool name by default, but this can be overridden by passing "ticketcreation-tool" as our tool name. We will pass the args_schema as TicketInputSchema as defined above using Pydantic. This will force the language model to first ensure the schema is validated before proceeding with tool invocation. Additionally, we will include a docstring to help the language model understand the purpose of this tool and the expected output structure. We will leverage JiraAPIWrapper provided by LangChain, which is a class that extends BaseModel and is a wrapper around atlassian-python-api. The atlassian-python-api library provides a simple and convenient way to interact with Atlassian products using Python. Python from langchain.utilities.jira import JiraAPIWrapper Let's look at the complete code: Python @tool("ticketcreation-tool", args_schema=TicketInputSchema) def ticketcreation( summary: str, project: str, description: str, issuetype: str, priority: str) -> dict: """ This tool is used to create a jira issue and returns issue id, key, links""" import json payload = json.dumps({ "project": { "key": project }, "summary": summary, "description": description "issuetype": { "name" : "Task" }, "priority": { "name": priority }, # "custom_field_10010":{ # "value": impact # } }) response = JiraAPIWrapper().issue_create(payload) return response We will use the code below to bind the tools with the model: Python tools = [ticketcreation] llm_with_tools = llm.bind(tools) Memory Management This solution will leverage ConversationBufferMemory. Python from langchain.memory import ConversationBufferMemory memory = ConversationBufferMemory(memory_key="history", return_messages=True) Defining the Prompt In a LangChain OpenAI prompt, system messages offer context and instructions, followed by placeholders for user input and agent scratchpad. The system message component in the prompt lets the model know the context and provides guidance. Here is a sample system message that I have used: Python ( "system", """ You are skilled chatbot that can help users raise Jira tickets. Ask for the missing values. Only Allow values from allowed enum values """, ) Our input variables will be limited to input, agent_scratchpad, and history. input will be provided by the user during invocation, containing instructions for the model. agent_scratchpad will encompass a sequence of messages containing previous agent tool invocations and their corresponding outputs. history will hold interaction history and generated output. Here is a sample history object: [HumanMessage(content='Can you help me create a jira ticket'), AIMessage(content='Sure, I can help with that. Please provide me with the details for the Jira ticket you would like to create.')], 'output': 'Sure, I can help with that. Please provide me with the details for the Jira ticket you would like to create.'} And here is the prompt code using ChatPromptTemplate: Python from langchain_core.prompts import ChatPromptTemplate, MessagesPlaceholder prompt = ChatPromptTemplate.from_messages( [ ( "system", """ You are skilled chatbot that can help users raise jira tickets. Ask for the missing values. Only Allow values from allowed enum values. """ ), MessagesPlaceholder(variable_name="history"), ("user", "{input}"), MessagesPlaceholder(variable_name="agent_scratchpad"), ] ) Agent Pipeline This pipeline represents the sequence of operations that the data goes through within the agent. The pipeline below is defined using the pipeline operator "|" which ensures that the steps are executed sequentially. Python from langchain.agents.format_scratchpad.openai_tools import format_to_openai_tool_messages from langchain.agents.output_parsers.openai_tools import OpenAIToolsAgentOutputParser agent = ( { "input": lambda x: x["input"], "agent_scratchpad": lambda x: format_to_openai_tool_messages( x["intermediate_steps"] ), "history": lambda x: x["history"], } | prompt | llm_with_tools | OpenAIToolsAgentOutputParser() ) The purpose of the "OpenAIToolsAgentOutputParser()" component in the pipeline is to parse and process the output generated by the agent during interaction. Agent Executor The agent executor serves as the core engine for an agent, managing its operation by initiating activities, executing assigned tasks, and reporting outcomes. The following code demonstrates the instantiation of AgentExecutor. Python from langchain.agents import AgentExecutor agent_executor = AgentExecutor(agent=agent, tools=mytools, verbose=True, memory=memory, max_iterations=3) Session Management To manage sessions when executing the tool, we will use ChatMessageHistory, a wrapper that offers easy-to-use functions for storing and retrieving various types of messages, including HumanMessages, AIMessages, and other chat messages. The RunnableWithMessageHistory encapsulates another runnable and oversees its chat message history. It's responsible for both reading and updating the chat message history. Python from langchain_community.chat_message_histories import ChatMessageHistory from langchain_core.runnables.history import RunnableWithMessageHistory message_history = ChatMessageHistory() agent_with_chat_history = RunnableWithMessageHistory( agent_executor, lambda session_id: message_history, input_messages_key="input", history_messages_key="history", ) By default, the encapsulated runnable expects a single configuration parameter named "session_id," which should be a string. This parameter is utilized to either create a new chat message history or retrieve an existing one. Python agent_with_chat_history.invoke( {"input": message}, config={"configurable": {"session_id": conversation_id}, ) Conclusion Integrating AI chatbots driven by large language models offers businesses a significant chance to enhance internal operations, streamlining project management and customer support. However, security and hallucination concerns may hinder immediate adoption by external consumers. Careful consideration of these factors is essential before implementing AI chatbots for customer-facing purposes.

By Rupali Kaushik

Microsoft Research Lab Structure: A Data-Driven Approach to Tech Leadership and Innovation

Microsoft Research, a key player in the technology research landscape, has established a unique lab structure that fosters tech leadership and innovation. In this article, we delve into the various aspects of Microsoft Research Labs' management approach, highlighting data-driven insights that showcase their success in fostering innovation and leadership. Encouraging Autonomy and Flexibility: Impact on Research Output Researchers at Microsoft Research enjoy a high level of autonomy and flexibility in selecting their research projects. This freedom nurtures creativity, risk-taking, and groundbreaking ideas. As a result, Microsoft Research has published over 20,000 peer-reviewed publications and filed more than 10,000 patents since its inception in 1991. Flat Organizational Structure: Accelerating Decision-Making Microsoft Research's flat organizational structure facilitates direct access to senior management and decision-makers. By reducing bureaucracy and streamlining decision-making, researchers can quickly pivot their projects and respond to new opportunities. This agility has contributed to the rapid development and integration of innovations like Microsoft Azure Machine Learning, HoloLens, and Xbox Kinect into commercial products. Goal Setting and Performance Evaluation: Fostering Collaboration Microsoft Research emphasizes setting clear goals and expectations for researchers, focusing on both short-term objectives and long-term visions. By tracking metrics such as collaboration levels, knowledge sharing, and interdisciplinary research, Microsoft Research has successfully fostered a culture of teamwork and innovation. For example, the company's annual internal TechFest event brings together researchers from different labs to showcase their work and collaborate on new ideas. Collaboration Tools and Platforms: Facilitating Global Connectivity Microsoft Research leverages various tools and platforms to facilitate seamless collaboration among researchers, both within and across labs. Researchers have access to cutting-edge resources like Microsoft Teams, SharePoint, and Azure DevOps, enabling them to work together efficiently across geographical boundaries. This global connectivity has led to numerous cross-lab collaborations, such as Project Premonition, which combines expertise from the Redmond, Cambridge, and New York labs to develop early warning systems for disease outbreaks. Internal Knowledge Sharing Events: Promoting Continuous Learning Microsoft Research organizes various internal events, such as conferences, workshops, and lecture series, where researchers can share their work, learn from others, and build relationships. These events have proven effective in fostering a culture of knowledge sharing and continuous learning. For instance, the Microsoft Research Faculty Summit brings together hundreds of academic researchers each year to discuss emerging trends and collaborate on new projects. Emphasis on Diversity and Inclusion: Driving Innovation Microsoft Research recognizes the value of diversity and inclusion in driving innovation. The organization actively promotes a diverse workforce, ensuring that researchers from different backgrounds, cultures, and perspectives can contribute their unique insights. As a result, Microsoft Research has received numerous accolades for its commitment to diversity, including being named one of the "Top 50 Companies for Diversity" by DiversityInc. Continuous Learning and Skill Development: Preparing Researchers for the Future Microsoft Research is committed to supporting the continuous learning and skill development of its researchers. The organization offers various resources, such as training programs, workshops, and access to online courses to help researchers stay up-to-date with the latest advancements in their fields and develop new skills. As an example, Microsoft Research's partnership with MIT's Computer Science and Artificial Intelligence Laboratory (CSAIL) allows researchers to participate in joint research projects and gain exposure to cutting-edge techniques. Conclusion Microsoft Research's lab structure plays a crucial role in fostering tech leadership and driving innovation. By encouraging autonomy, promoting collaboration, setting clear goals, leveraging modern tools, and emphasizing diversity and continuous learning, Microsoft Research creates an environment where researchers can thrive and contribute to the cutting edge of technology. The data-driven insights presented in this article demonstrate the effectiveness of Microsoft Research's management approach, serving as a model for other organizations looking to foster innovation and develop tech leaders of the future.

By Arun Pandey

CORE

The Impact of Technical Ignorance

I knew a Chief Software Architect from a major financial organization who was an anomaly: he had never developed software professionally. His undergraduate degree is in Accounting and Finance, and his most hands-on technology role was as a DBA. [His LinkedIn profile lists an early Programmer role, though he insisted he didn’t.] Even so, he was well-respected within his organization for his thought leadership and solutions, but nevertheless, it seemed an unusual career path. Since I last worked with him, he has moved into C-level roles at other organizations, confirming his abilities as a technology leader. Then I thought of others I have worked with who are non-technical but positioned to impact technical direction and realized their lack of understanding impacted (and continues to impact) the quality of the software solutions we, as engineers, are expected to deliver. Chief Non-Technical Officer This CTO has been with her/his company for many years in many roles: Director of Support, Chief Strategy Officer, Chief Cultural Officer, and Chief Technical Officer. S/he does not deny that s/he is not a strong technologist – and at times a badge of honor – yet confidently states decisions and direction that they become a fait accompli: alternatives that challenge her/his understanding are not often well received. At times, her/his inner circle helps to form a more nuanced understanding, but only to a point: overcoming her/his existing preconceived notions is difficult, and blatant opposition results in being sidelined from future discussions. By no means is s/he a total technical novice, but fundamental change requires extensive effort and time. Her/his oft-repeated mantra went something like this: Don’t tell me you’re refactoring; refactoring brings no value to our customers. Harking back to her/his strategy days, where feature-feature-feature is the overwhelming driver, this mantra confirmed her/his denial or lack of understanding of the current state of the product. The growing and maturing customer base made clear that areas of the product needed love and attention, but proposed efforts to address them were not prioritized because – in her/his view of the world – there was no visible benefit to their customers, at least when focused on customers asking for new or extended features. The real technologists of the company understood the potential benefits to both the customer and company: performance and scaling improvements, reduced cloud costs, faster deployments, fewer outages, faster feature delivery, reduced technology stack, and consistent and intuitive user experience. Regardless of potential benefits, nothing called out as refactoring would survive planning. The problems continued to grow, and the problems continued to be ignored. Sigh. Product To be clear, I have no interest in becoming a product owner: the wide-ranging responsibilities require a breadth of knowledge and experience not often found in a single person, while their many stakeholders – both internal and external – have contradictory goals and agendas that need to be balanced. I view it as a political role, finding compromises that please (appease) most, with no one getting everything s/he desired. This role is not for the weak and timid. Once we accept that product owners are unlikely to have the background or experiences necessary to handle all responsibilities, we can then understand why the focus is on those responsibilities understood or deemed important by their leaders. Outside of organizations offering technical solutions, product owners often have a stronger business understanding than technology understanding based on their work experience. Perhaps not surprisingly, the product is defined by business expectations more so than technical requirements: future features and functionality are defined by understanding industry trends, reviewing customer feedback, interpreting — sales and usage analytics, defining the user experience, etc. In essence, the product owner is an overclocked business analyst. Real-World Example A particular product manager focused only on rapidly releasing new features regardless of technical stability. Over time, the issues rose to the point where outages – not processing failures, actual outages – occurred daily and could no longer be ignored. She continued to view the work as unnecessary and not beneficial to the product, resulting in this exchange during quarterly planning: The result is product owners often eschew – whenever possible – technology and technical viability aspects of the product, reducing the impact of technology during product planning. Instead of top-down planning, individual engineers attempt to push technical issues bottom-up, which is very difficult and often unsuccessful. Organizations require a strong engineering discipline and culture to offset the business focus of product owners, but it remains a frustrating challenge. [Of course, production technology issues do arise that demand immediate attention, but the resulting work is stressful, particularly for the engineers who are responsible for implementing the changes required; the result is often a one-off effort rather than fundamentally changing the overall culture.] The Not-Ready-For-Prime-Time Implementation This is less about an individual or role but rather an organizational culture problem: proof-of-concepts assumed to be production-ready. Software proofs-of-concept (POCs) are created to test new business concepts or determine the usefulness or applicability of new technology. POCs should be created with minimal engineering rigor that allows a quick and cheap implementation to be discarded without guilt once the results are evaluated. Most important, it is not intended to be a workable product. Despite these clear expectations, too often, I’ve seen the business get excited at seeing the POC and want it available to customers immediately. The POC might be slightly enhanced or it might be unaltered, but it’s out there for the world (internal or external) to use. And when the problems start appearing – because, by definition, it was not intended for real-world usage – the finger-pointing begins. Agile advocates snigger and say You needed an MVP, silly! but my experiences are much the same as POCs: poor. By definition, an MVP is a complete application without the bells and whistles, but corners are inevitably cut: crawling (of crawl/walk/run paradigm) when current volumes require walk, run, or even fly; minimal/non-existent observability; non-standard user experience; incomplete or incorrect API definitions; security through obscurity; incomplete error handling. When leaders decide to move forward after a successful MVP, the expectation is to expand and enhance the MVP implementation; in fact, it may be better to start over. [I am not disavowing MVPs’ usefulness but rather am clarifying that organizations misuse/abuse the term and are, in fact, creating glorified POCs that are not complete, are not ready for users, and are not production ready. Just saying…] So when you next hear of an access application that is integrated into the enterprise supply chain workflow, don’t say I didn’t warn you. Organizations who make ignorant decisions on the production-readiness of applications shouldn’t know why failures occur later, yet they do, and the engineers are left to pick up the pieces. What Can You Do? It’s not hopeless, really. It isn’t …. not necessarily fun, but there are strategies that you can attempt. Gather Create a personal archive of articles, use cases, scenarios, and data that allows you to tell stories to non-technical people, helping them understand the tradeoffs present in all organizations. Internally, you might be interested in estimated vs. actual effort for feature delivery, production failure rates, or implementation costs mapped to the customer base. Are cloud costs increasing faster than customer growth? Did assumptions made during initial implementation impact the ability to deploy future features, whether positive or negative? Is supposedly important work upended by unknown and unplanned initiatives? Did a potential security breach impact customer confidence? What was the cost of researching a potential security breach? Is data quality affecting your reporting, analytics, and billing? There are many different ways to try and understand what’s happening within your organization. Almost daily, there are new articles online that highlight the issues and problems other organizations experience: Southwest’s 2022 holiday meltdown, a ransomware attack on Vital Care Providers, and Cloudfare’s bad software deployment. Not every organization publishes postmortems, but details often leak through other channels. Perhaps more importantly, your organization doesn’t want to appear in those articles! Educate As most non-technical folks appear unable or unwilling to accept that software is hard, our responsibility – for better or worse – is to show and explain. Unique situations require adjusting the story told, but it is necessary – and never-ending – to have any chance to get the organization to understand: explaining how software is developed and deployed, demonstrating how a data-driven organization requires quality data to make correct decisions, explaining the advantages and disadvantages of leveraging open source solutions; showing examples of how open source licenses impact your organization’s intellectual property. Look for opportunities to inject background and substance when appropriate, as education is open-ended and never-ending. Often, it will appear no one is listening as you repeat yourself, but eventually – hopefully – someone will parrot what you’ve been saying for months. Negotiate Aside from those employed in purely research and development roles, engineering/technology for engineering/technology's sake is not feasible, as technology concerns must be balanced with business concerns: product and its competitors, sales pipeline, customer support and feature requests, security, privacy, compliance, etc. Each decision has its short- and long-term impacts, and it is very unlikely that all involved will be pleased. Sorry, but that’s corporate politics. That does not mean you roll over and play dead, but rather horse trade, often with management and product, to ensure the technical concerns aren’t forgotten: Ensure that changes in business priorities are coupled with impact analysis on in-process development efforts; Accept less-than-optimal initial implementations with the agreement of fast-follow work to address compromises; Define metrics that identify when technology-focused work should be prioritized over feature work. These ideas may or may not apply to your organization or situation, but hopefully, they will give you ideas that may be pursued. Conclusion The problems I’ve discussed are age-old and have seemed to become worse in recent decades, so I’m not sure if any of what I’ve discussed is a surprise. Perhaps this is only the latest incarnation of the problem and post-Agile a new approach will reap benefits. Perhaps leaders will acknowledge that engineers really do understand the problems and are trusted to implement a solution rather than given solutions that fit an arbitrary (and often unrealistic) timeline. It’s a tug-of-war that I don’t yet see resolved. Image Credits “Pointy Hair Boss” © Scott Adams “Productivity: Putting the Kanban Display Together” by orcmid is licensed under CC BY 2.0. “Analog circuit board prototype” by mightyohm is licensed under CC BY-SA 2.0.

By Scott Sosna

CORE

How To Implement Code Reviews Into Your DevOps Practice

DevOps encompasses a set of practices and principles that blend development and operations to deliver high-quality software products efficiently and effectively by fostering a culture of open communication between software developers and IT professionals. Code reviews play a critical role in achieving success in a DevOps approach mainly because they enhance the quality of code, promote collaboration among team members, and encourage the sharing of knowledge within the team. However, integrating code reviews into your DevOps practices requires careful planning and consideration. This article presents a discussion on the strategies you should adopt for implementing code reviews successfully into your DevOps practice. What Is a Code Review? Code review is defined as a process used to evaluate the source code in an application with the purpose of identifying any bugs or flaws, within it. Typically, code reviews are conducted by developers in the team other than the person who wrote the code. To ensure the success of your code review process, you should define clear goals and standards, foster communication and collaboration, use a code review checklist, review small chunks of code at a time, embrace a positive code review culture, and embrace automation and include automated tools in your code review workflow. The next section talks about each of these in detail. Implementing Code Review Into a DevOps Practice The key principles of DevOps include collaboration, automation, CI/CD, Infrastructure as Code (IaC), adherence to Agile and Lean principles, and continuous monitoring. There are several strategies you can adopt to implement code review into your DevOps practice successfully: Define Clear Goals and Code Review Guidelines Before implementing code reviews, it's crucial to establish objectives and establish guidelines to ensure that the code review process is both efficient and effective. This helps maintain quality as far as coding standards are concerned and sets a benchmark for the reviewer's expectations. Identifying bugs, enforcing practices, maintaining and enforcing coding standards, and facilitating knowledge sharing among team members should be among these goals. Develop code review guidelines that encompass criteria for reviewing code including aspects like code style, performance optimization, security measures, readability enhancements, and maintainability considerations. Leverage Automated Code Review Tools Leverage automated code review tools that help in automated checks for code quality. To ensure proper code reviews, it's essential to choose the tools that align with your DevOps principles. There are options including basic pull request functionalities, in version control systems such as GitLab, GitHub, and Bitbucket. You can also make use of platforms like Crucible, Gerrit, and Phabricator which are specifically designed to help with conducting code reviews. When making your selection, consider factors like user-friendliness, integration capabilities with development tools support, code comments, discussion boards, and the ability to track the progress of the code review process. Related: Gitlab vs Jenkins, CI/CD tools compared. Define a Code Review Workflow Establish a clear workflow for your code reviews to streamline the process and avoid confusion. It would help if you defined when code reviews should occur, such as before merging changes, during feature development, or before deploying the software to the production environment. Specify the duration allowed for code review, outlining deadlines for reviewers to provide feedback. Ensure that the feedback loop is closed, that developers who wrote the code address the review comments, and that reviewers validate the changes made. Review Small and Digestible Units of Code A typical code review cycle should involve only a little code. Instead, it should split the code into smaller, manageable chunks for review. This would assist reviewers in directing their attention towards features or elements allowing them to offer constructive suggestions. It is also less likely to overlook critical issues when reviewing smaller chunks of code, resulting in a more thorough and detailed review. Establish Clear Roles and Responsibilities Typically, a code review team comprises the developers, reviewers, the lead reviewer or moderator, and the project manager or the team lead. A developer initiates the code review process by submitting a piece of code for review. A team of code reviewers reviews a piece of code. Upon successful review, the code reviewers may request improvements or clarifications in the code. The lead reviewer or moderator is responsible for ensuring that the code review process is thorough and efficient. The project manager or the team lead ensures that the code reviews are complete within the decided time frame and ensuring that the code is aligned with the broader aspects of the project goals. Embrace Positive Feedback Constructive criticism is an element, for the success of a code review process. Improving the code's quality would be easier if you encouraged constructive feedback. Developers responsible, for writing the code should actively seek feedback while reviewers should offer suggestions and ideas. It would be really appreciated if you could acknowledge the hard work, information exchange, and improvements that result from fruitful code reviews. Conduct Regular Training An effective code review process should incorporate a training program to facilitate learning opportunities for the team members. Conducting regular training sessions and setting a clear goal for code review are essential elements of the success of a code review process. Regular trainings play a role, in enhancing the knowledge and capabilities of the team members enabling them to boost their skills. By investing in training the team members can unlock their potential leading to overall success, for the entire team. Capture Metrics To assess the efficiency of your code review procedure and pinpoint areas that require enhancement it is crucial to monitor metrics. You should set a few tangible goals before starting your code review process and then capture metrics (CPU consumption, memory consumption, I/O bottlenecks, code coverage, etc.) accordingly. Your code review process will be more successful if you use the right tools to capture the desired metrics and measure their success. Conclusion Although the key intent of a code review process is identifying bugs or areas of improvement in the code, there is a lot more you can add to your kitty from a successful code review. An effective code review process ensures consistency in design and implementation, optimizes code for better performance and scalability, helps teams collaborate to share knowledge, and improves the overall code quality. That said, for the success of a code review process, it is imperative that the code reviews are accepted on a positive note and the code review comments help the team learn to enhance their knowledge and skills.

By Joydip Kanjilal

CORE

Sprint Retrospective Meeting: How To Bring Value to the Table

A sprint retrospective is one of the four ceremonies of the Scrum. At the end of every sprint, a product owner, a scrum master, and a development team sit together and talk about what worked, what didn’t, and what to improve. The basics of a sprint retrospective meeting are clear to everyone, but its implementation is subjective. Some think the purpose of a sprint retrospective meeting is to evaluate work outcomes. However, as per the Agile Manifesto, it is more about evaluating processes and interactions. It says, “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” Many scrum teams are not making most of the sprint retrospective meetings due to a lack of understanding. In this post, we will look at what to avoid in a sprint retrospective meeting and what to do to run an effective sprint retrospective meeting. What To Avoid in a Sprint Retrospective Meeting? A sprint retrospective meeting is an opportunity for the scrum team to come together and discuss the previous sprint with the purpose of making improvements in processes and interactions. But scrum teams often end up making a sprint retrospective meeting a negative talk of beating one another and less interesting due to the lack of implementation of outcomes of sprint retrospective meetings. Here are a few things that you need to avoid in a sprint retrospective meeting: 1. Focusing on the Outcomes The end goal of a sprint retrospective is undoubtedly increasing the sprint velocity of the team, but the process to do so is not talking about the outcome of the sprint. The focus is on finding areas that can be improved in processes and people to make it easy and efficient for the scrum team to work together. 2. Not Involving All Team Members’ Voice The output of a scrum team is evaluated as a team, not as each individual. Therefore, it is important that each member of the Scrum team is heard. Thus, the equal participation of the team members is required in retros. If someone has issues and they are not addressing them, it is going to impact the sprint output as the members of the sprint team are highly dependent on each other to achieve sprint goals. 3. Talking Only About What Went Wrong The purpose of a sprint retrospective is to make improvements, but it does not mean you do not talk about good things. We all are human beings and need appreciation. If you talk only about what did not work, a sprint retrospective will become more of a tool of blaming and beating each other rather than an instrument of improvement. Above all, it is important to talk about what went well so that you can replicate good things in the next sprint. 4. Not Taking Action on Retro Outcomes The worst thing that can happen for a sprint retrospective is not taking action items derived from it. This will lead to a loss of interest and trust in sprint retrospectives as it sends a message to the team that their feedback is not valuable. What To Do To Run an Effective Sprint Retrospective Meeting There are some basics you can follow to run an effective sprint retrospective meeting. Have a look at them. 1. Create a Psychologically Safe Space for Everyone To Speak It is the responsibility of a product owner and a scrum master to create a psychologically safe environment for everyone to speak up in the meeting to make a sprint retrospective successful. If you are asking questions like what went well during the last sprint, what didn’t go well, and what should we do differently next time, everyone should feel safe to share their views without any repercussions. 2. Use a Framework The best way to conduct an effective sprint retrospective meeting is to follow a template. Experts have created various frameworks for conducting effective sprint retrospective meetings. The top frameworks include: Mad, Sad, Glad Speed car retrospective 4 L's Retrospective Continue, stop, and start-improve What went well? What didn't go well? What is to improve? These frameworks help ensure that you are talking about processes, not people. For example, the Mad, Sad, Glad framework talks about asking what makes the team mad, sad, and glad during the sprint and how we can move from mad, sad columns to glad columns. Use a framework that works for your scrum team. 3. Have a Facilitator-In-Chief Like any other meeting, a sprint retrospective meeting needs to have a goal, a summary, and a facilitator. Have a facilitator-in-chief to make sprint retrospectives valuable. Usually, the role is dedicated to the scrum master whose responsibility in sprint retrospective is to: Set the agenda and goals of the sprint retrospectives. Collect feedback from all the team members on the action items to talk about in the retro. Defining the length of the meeting. Follow up with action items implemented in the last sprints. Summarizing the key action items for the next sprint. 4. Implement the Action Items The responsibility of the scrum master does not end with a sprint retrospective. A scrum master needs to make sure that action items found in the sprint retrospective are implemented in the upcoming sprint. Daily stand-up meetings are a great tool for the scrum master to ensure that the team is implementing what is agreed upon & discussed and making improvements. Also, you can see the results of sprint retrospectives in tangible terms with metrics like sprint velocity. 5. Positivity, Respect, and Gratitude for Everyone Lack of engagement is the biggest challenge of sprint retrospectives in the long run. It occurs when action items are not worked on, people are not heard, and the focus is on negatives. Cultivate positivity and have respect and gratitude for everyone. Talks about what can be improved rather than blaming individuals. Listen to others to mark respect and express gratitude to address everyone’s contributions. Paired with the implementation of action items, you can ensure that your scrum team sees sprint retrospectives as an opportunity to improve. Conclusion Sprint retrospective is a great opportunity to look past what worked well, what went wrong, and what we can do ahead to improve. It is a great instrument for a business to improve efficiency, keep its workforce happy, and build products that both clients and end-customers love. The only challenge is you need to utilize it appropriately. With insights shared in this post, there are high chances you will be able to run effective sprint retrospective meetings and bring actual value to the table.

By Sandeep Kashyap

Navigating the Challenges of Rapidly Scaling Your Engineering Team

In this article, we are going to look at the challenges faced when rapidly scaling engineering teams in startup companies as well as other kinds of companies with a focus on product development. These challenges change between different types of companies, sizes, and stages of maturity. For instance, the growth of a consultancy software company focused on outsourcing is so different from a startup focused on product development. I've faced much team growth and also seen the growth of teams in several companies, and most of them have faced the same challenges and problems. Challenges The following are some of the challenges or problems that we will have to address in high-growth scenarios: Growth is aligned with productivity: many companies grow, but the output is unfortunately far from the goals. Avoid team frustration due to failure to achieve growth goals. Avoid too much time being consumed with the hiring process for the engineering teams. Avoid the demotivation of newcomers due to chaotic onboarding processes: the onboarding process is the first experience in the company. Maintain and promote the cultural values defined by the organization. The impact on delivery is aligned with the defined goals and risks. New hires meet expectations and goals in terms of value contribution. Navigating the Challenges Goals Goals are the main drivers of the growth strategy. They need to be challenging, but also realistic, and linked to mid-term and long-term vision. Challenging: Push the team to go beyond their comfort zone and strive for excellence. It requires effort, innovations, planning, and agility. Realistic: Ensure the goals can be achieved to avoid lead with frustration and burnout. The growth of the company and its success have to enhance the motivation and inspiration of the team. Long-term: Goals have to be aligned with the company's long-term vision and in a wide range. Large growth cannot be organized with the next three months in mind, because that may be the time it takes to find suitable candidates. Goals have to be measurable, clear, and specific to: Promote accountability Evaluate and measure the goal's success Take data-driven decisions All growth requires dedication and effort from the team; time that they will not dedicate to product evolution or development. Example: Unrealistic Goal Let's suppose we have a team of 10 engineers divided into 2 squads: backend and platform. The company set the following goals: Triplicate the team in 1 year, from 10 to 30 engineers. Keep the delivery performance. Create three news squads: DevOps, Data Platform, and Front End. Promote the culture. Only hire top-tier engineers. Most likely, the number of candidates we will have to evaluate in interviews and technical exercises will be at best four candidates for each position in addition to the time dedicated to the onboarding process. Usually, there is more than one engineer collaborating in the hiring process so we are likely to have a significant impact on delivery. Finding a team of experienced and highly qualified people is not an easy task. It is necessary to define what we consider "talent" and the different levels at which we can hire. Maintaining and promoting the culture in a high-growth environment where in one year there are more new people than the team we have is very complex and requires a good strategy, definition of objectives, and agility in decision-making. With this, we want to reflect that one of these objectives would already be ambitious - but all of them together make it practically impossible to achieve success. Talent Acquisition and Hiring Process The talent acquisition team plays a crucial role in a company's growth strategy, but they need the support of all of the company. C-Levels and hiring managers have to provide all the support and be involved as the same team. Clear Communication Foster open and clear communication between teams to ensure that everyone understands the goals and the role each team plays in the process. Review Pipeline Quality Sometimes many candidates go through the early stages of the pipeline and are ultimately discarded, and this generates a lot of frustration in the engineering team because the analysis of each candidate requires significant effort. It is important to adjust the requirements and search criteria for candidates in the early stages of the pipeline and this requires constant communication between the teams. Market Knowledge Talent acquisition teams should provide insights into market trends and competitor strategies. This knowledge provides important information to the company to define the expectations and strategy and stay ahead in the market. Cultural Values It is important to keep in mind that each engineer who joins our team brings his or her own culture based on factors such as work experience, personality, or the country where they live. Although these people fit the cultural pattern we are looking for, most of the time they do not have the culture of the company, and the hiring process is not reliable. If maintaining the culture is important to the company, we need to mentor new employees starting with the recruitment process itself. Promote values in the hiring process. Promote values in the company and team onboarding process. Promote values during the first years through the mentoring process. Promoting the cultural values and the company's goal are tasks that must be done continuously, but we must reinforce and review them with new hires more frequently. On-Boarding In my opinion, the onboarding process has a huge role in almost all companies and is not given enough attention. It is especially important in high-growth companies. The two main problems are: No onboarding process: Onboarding is focused on a meeting with human resources, another with the manager, and finally the team: a three-hour process. This can only be considered as a welcome meeting. Highly technical processes: Processes very oriented to perform your first deployment and that mainly promote knowledge silos and little engagement with the company. The onboarding process must be led by the organization. It must be structured and must encourage a smooth integration of new hires into the organization, minimizing disruptions and maximizing productivity over time. In addition, the entire onboarding process should be a step-by-step process with as much documented support as possible. This would be a base structure for a complete onboarding process: Pre-boarding: It includes all the activities that occur between the acceptance of the offer and the new hire's first day. Continuous communication is important because it promotes motivation and cultural values and helps to create a feeling within the company. Welcome Day: Welcome meeting, company overview, review of company policies and cultural values Paperwork, documentation, and enrollment processes Initial equipment setup Introduction to Team and Manager Security training Company 360 (scheduled by month): 360-degree meetings with leaders from all departments provide valuable insights, foster collaboration, and help new employees understand the broader organizational context. Starting the first week: Cultural values and goals: The manager and the team share the same cultural values and team goals. The goals have to be clear and most of them measurable. Mentorship: Assign a mentor to support the integration process at least during the first year. Engineering Tech best practices and tools: Share the vision of architecture principles, DevOps, data principles, tools, and best practices of the organization. Roles-specific training Team integration: Start participating in team meetings. Feedback and evaluation: Feedback must always be continuous, honest, and constructive. We must put more emphasis on new hires to adjust goals, mentoring, or training. It would be better to start with one-to-one and include this evaluation and feedback in these sessions. Starting in the third month: Performance evaluation Continuous learning is part of the cultural values but at this time learning paths could be considered Initiate conversations about long-term career paths. It is important to avoid onboarding processes based solely on pairing or shadowing strategies because they require too much effort and also only generate silos and misalignment. These sessions are important but must be supported by documentation from both the organization and the team itself. Impact on Delivery The growth phase often requires a high investment of time, effort, and people in the hiring and onboarding process. Hiring process: Participating in technical sessions, reviewing candidate profiles, and reviewing technical exercises. Onboarding: The process of onboarding a new engineer to a team is always time-consuming and usually involves a learning curve until these people can offer more value than the effort invested in their integration. In the case of large growth, there may be situations in which teams are formed entirely by new engineers. This also has an impact on delivery, because these teams need: Mentors and support to adapt to the new environment Transversal coordination with other squads Talent Density In my opinion, growth should be based on the amount of talent and not on the number of engineers. At this point, there are a number of aspects to consider: What does talent mean to our organization? Finding talent is very complicated. There is a lot of competition in the market, people specialized in hiring processes, and the pressure to grow. Many people mistake talent for knowledge or years of experience. In my case, I have always given more value to the person's potential for the new role and for the organization rather than the experience in the role or the companies in which he/she has worked. The fit of a new hire is not only restricted to the hiring process but also to the evaluation period. Moreover, it is during the evaluation period that we can really evaluate the person. It is in this period when the decision is less painful for both parties, a person who does not fit in the organization will generate a negative impact both for him and for the organization. Team Topology These growth scenarios require changes in the organization and the creation of new teams or departments. Two fundamental factors must be taken into account: Team creation strategy Conway's Law Team Creation Strategy There are several strategies for developing the organization of teams: Integrate new hires into existing squads. Integrate new hires into existing squads and after some time, divide the team in two. Create entirely new teams with new hires. Create a new team from current leadership and new hires. The decision to apply a single approach or a combination of several approaches depends on several factors, including the organization's specific needs, resource availability, and long-term objectives. Conway's Law Conway's Law is a principle in software engineering and organizational theory: Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. Conway's Law suggests that the communication patterns, relationships, and team structures within an organization are reflected in the architecture, design, and interfaces of the software or systems they build. Summary The growth of engineering teams is one of the most complex challenges facing a growing organization, especially if this growth must be aligned with productivity and cultural goals. Hiring the number of people we have set as a target can be easy. Hiring the right people can be almost impossible and hiring a ratio of enough talented people is very difficult. This can only be done well if you work as a team.

By Miguel Garcia

CORE

Team Management

DZone's Featured Team Management Resources

Top Team Management Experts

The Latest Team Management Topics