Team Management

In cybersecurity, professionals are often divided into two distinct groups: Red Teams, which focus on offense, and Blue Teams, which focus on defense. Red Teaming involves ethical hacking. Here, security experts simulate cyberattacks to find vulnerabilities in a system before malicious actors can exploit them. On the other hand, Blue Teaming is all about defending the system from such attacks. Blue Team members monitor, detect, and respond to security incidents. For developers, understanding the dynamics of both Red and Blue Teams is very important. Developers are often on the front lines of building and securing applications. They must consider how their work fits into the broader security landscape. Whether you are writing code for a new app or patching vulnerabilities in apps after a security breach, knowing the strategies and challenges of both teams can make you a more well-rounded professional. Let's explore the recruitment and advanced training of specialists focused on countering cyberattacks, known as the Blue Team. We will examine the distinct career paths and training strategies, focusing on the contrasting roles of Blue Teaming (defense) and Red Teaming (offense). In this article, you will find why many students are drawn more to Red Teaming rather than Blue Teaming. We will also touch upon training methodologies, the importance of balancing theory with practical experience, and initiatives to make Blue Teaming more attractive and accessible to budding cybersecurity professionals. Decoding Career Preferences Many students are captivated by the appeal of becoming ethical hackers, finding it both thrilling and trendy. While they are aware of the Blue Team's role, they often struggle to grasp the career trajectory. While defensive security is now a familiar concept, offensive security remains relatively unusual. The uniqueness of offensive roles, filled by the Red Team, makes them more appealing due to higher salaries and greater opportunities for personal achievement. Consequently, more young specialists are attracted to these positions. Clearly, the defensive role, or Blue Team, needs to be made more accessible and appealing to future specialists to balance the appeal between offensive and defensive cybersecurity roles. It is important to communicate the long-term career benefits and security that come with Blue Team roles to counterbalance the initial allure of Red Teaming. A significant challenge here is the widespread belief that defensive roles are not as prestigious. So, it is essential to better showcase the critical impact and intellectual challenge Blue Team jobs offer. In addition, to enhance the Blue Team's attractiveness, it is good to implement structured mentorship programs that highlight career progression and stability, which are appealing to those looking for long-term growth. Despite having more skilled specialists, the role of the Blue Team, which focuses on building foundational cybersecurity knowledge and skills, has become less visible. Attackers often hold the upper hand with the flexibility to choose their tactics and timing, forcing defenders to react swiftly and under significant pressure. Defense requires thorough, time-intensive thought in building protection lines and routine work, in contrast to the Red Team, where students and young specialists often prefer quicker, more visible results. In Blue Teams, staff handle the routine job of monitoring alerts and constructing defenses. On the other hand, Red Team members carry out more lively tasks, attacking systems using different methods. By frequently updating training modules to cover various attack types, Blue Team roles can become more engaging and exciting. It is important to note that working on the Red Team often leads to job burnout, resulting in many specialists transitioning to the defensive side. Typically, career progression involves achieving success on the Red Team before moving to the more stable Blue Team. Business owners should recognize that equipping the Blue Team with better tools and visibility can prevent burnout and enhance their effectiveness, safeguarding the business more efficiently. The average salary of a Blue Team specialist is considered very attractive. However, the rewards that white hackers earn through Bug Bounty programs for discovering vulnerabilities can be significantly higher. There is a noticeable gap between market demands and the capabilities of specialists. Some companies fail to find great people for the Blue Team because there are no experienced specialists who want to change jobs. Young Blue Team specialists often lack a thorough understanding of attacker techniques, tactics, and infrastructure. They need more skills in areas like OSINT, analyzing breach data, and deep web research. So, to attract good specialists, they must either be highly motivated or well-supported in their training. It is good that there are now enough training courses. Assessing and Improving Blue Team Skills Training in realistic combat scenarios is highly effective. It is advised to use cyber exercises to hone teamwork skills. Although it might be trickier to assess individual performance, these exercises offer valuable insights. Teamwork is what matters most in businesses, so evaluating individual performance in these exercises might be less important. Adding mentors to these exercises can spot knowledge gaps on the spot, allowing for immediate correction. Junior cybersecurity professionals can jumpstart their careers by honing core skills quickly through hands-on training at cyber ranges. Following this initial training, participating in Purple Team exercises can elevate their skills to an even higher level, pushing them towards expertise. Consider establishing a rotational program within your company. This would expose young infosec professionals to diverse security areas and roles, fostering a well-rounded skillset and deeper understanding of the field. However, practical experience thrives alongside a strong theoretical foundation. Without the underlying knowledge, hands-on work can lack direction and focus. For this reason, combining theory with practice while maintaining a balance is crucial. Effective cybersecurity training caters to various learning styles. Additionally, a well-structured program with multiple levels should progressively develop skills, taking professionals from foundational knowledge to advanced expertise. This personalized and progressive approach ensures every team member gains maximum benefit. Remember, it is important to train not only the Blue Team but all company specialists to ensure comprehensive security. When everyone on the team is informed and ready to respond to security threats, the company's overall defenses are much stronger. Cultivating Cyber Talents Among Students Since training cybersecurity professionals can be time-consuming, companies often seek candidates with pre-existing skills. Universities with on-site Security Operations Centers (SOCs) and realistic cyber exercises are proving to be valuable talent pipelines. Businesses can tap into this pool by recruiting students as early as their junior year. Cybersecurity vendors and related companies always offer a range of training options for specialists, from virtual training grounds to specialized vendor courses. Hackathons, university partnerships, and internship programs further enrich the talent pool. To attract future talent, regular industry events and career fairs showcase real-world security applications. Cutting-edge recruitment methods, like AI-powered sourcing and decision-making, can help companies find top talent quickly. Students should actively seek internships or part-time roles that offer experience in cybersecurity to complement academic studies and provide a competitive edge in the job market. As a student, seeking internships in both Red and Blue Teams, as well as exploring potential IoT career paths, cloud security, or digital forensics, can provide a balanced perspective and a better understanding of each role's contributions to cybersecurity. Evolving Blue Team Job Market The value placed on enhancing the cybersecurity skills of Blue Teams is being reevaluated. Until recently, very little funding was allocated to staff development; however, this trend is now shifting. Collaboration with universities is crucial for businesses. Previously, graduates often lacked a clear career direction after graduation. Now, partnerships with universities allow students to identify specific career paths during their studies, which significantly benefits the industry. Collaboration between vendors and universities is set to grow. Vendor specialists are increasingly teaching at universities, and comprehensive programs from leading cybersecurity providers are emerging. Final Thoughts Blue Teaming's career path can be unclear for some young professionals, who might find Red Teaming's focus and immediate impact more appealing. While Blue Teaming involves dedicated effort, the repetitive tasks of offensive roles can lead to a sense of monotony. However, defensive security offers a deeper well of skill development. To address this, there is a growing range of courses, hackathons, and resources actively encouraging students to pursue the defender role.

TL; DR: The Pre-Mortem: A Non-negotiable Part of Your Product Development Toolbox Do you want to build products that avoid costly mistakes, meet customer needs, and drastically enhance your career prospects? The the pre-mortem is your secret weapon! By imagining how a project might fail before it even begins, teams can identify and mitigate hidden risks early, ensuring a more resilient, successful outcome. This article explains why pre-mortems are a brilliant tool for risk mitigation, improving your team’s decision process, and how they can transform your product development process. Learn how to apply this proactive strategy and create bulletproof products. The Pre-Mortem: A Brilliant Strategy for Risk Mitigation in Product Development Success is often measured by how quickly we launch new features or products; time-to-market is essential to beat your competition. However, speed alone is not enough — what truly defines success is a product’s ability to meet user needs while avoiding costly mistakes. This is where the concept of a pre-mortem becomes invaluable. As a proactive risk-mitigation technique, the pre-mortem allows teams to identify and address potential failure points before they occur, enhancing their decision-making process. Unlike traditional post-mortems, which occur after a project has failed, a pre-mortem involves envisioning a project as having already failed before it even begins. By asking, “What went wrong?” teams can explore possible reasons for failure and implement strategies to mitigate those risks. This ingenious approach enhances problem-solving and supports the creation of more resilient products that are better aligned with both customer needs and business objectives. The Inversion Principle at the Core of the Pre-Mortem The inversion principle is at the heart of the pre-mortem, which means thinking about a problem backward. Instead of asking, “How can I succeed?” you ask, “How can I fail?” This flipping of perspectives helps you see things you might not notice otherwise. This concept is central to Charlie Munger’s investment philosophy and is, for example, also used in Liberating Structures’ TRIZ microstructure. In both cases, the goal is to improve outcomes by deliberately examining how things could go wrong. By inverting the problem, teams can identify weaknesses and blind spots that might otherwise remain hidden. How a Pre-Mortem Works The mechanics of a pre-mortem are simple yet powerful. A typical pre-mortem session begins with the assumption that the product or feature has failed spectacularly. The team then engages in a brainstorming exercise, imagining and documenting every possible reason for the failure. Whether it’s unrealistic timelines, misaligned customer expectations, or technical limitations, no reason is too outlandish to consider. Once the potential causes of failure are identified, the team works backward to address these issues. They ask, “How can we prevent this from happening?” This process encourages creative problem-solving by prompting the team to consider risks they may not have otherwise considered. It also fosters collaboration as the team collectively works to address and mitigate potential pitfalls before they become actual threats. By approaching risk from this inverted perspective, the pre-mortem moves beyond surface-level concerns and digs deeper into structural, organizational, and even cultural issues that might cause problems down the line. It empowers teams to think critically about their decision-making process, revealing hidden risks that could jeopardize the project. As a result, teams are better equipped to create contingency plans and design more resilient products. Best of all, all of this happens in a blame-free environment as the actual work hasn’t yet been started — it is all hypothetical! Why Pre-Mortems Are Essential in Product Development In product development, uncertainty is a given. Whether it’s developing an entirely new product or adding a critical feature, the path to success is often fraught with unknowns. Market conditions change, customer needs evolve, and technical challenges can arise anytime. A pre-mortem is a strategic buffer against these uncertainties, allowing teams to anticipate and address them proactively: Identifying hidden risks early: One of the greatest strengths of the pre-mortem is its ability to surface hidden risks. In many product development cycles, risks are only identified after investing significant time and resources. By that point, addressing these issues can be costly and disruptive. The pre-mortem ensures that teams can identify risks early, allowing them to adjust their strategies before committing substantial resources. Encouraging a safe environment for honest feedback: Traditional risk assessments often fail because team members hesitate to voice concerns, either out of fear of being seen as negative or because they don’t want to challenge the status quo. In contrast, the pre-mortem creates a safe space for critical thinking by explicitly encouraging team members to imagine the worst. This aspect removes the stigma of negativity and fosters an environment where candid feedback is accepted and encouraged. Enhancing decision-making through collaboration: Pre-mortems also promote collaboration and support better decision-making. By involving cross-functional teams, organizations can draw on diverse perspectives to identify risks that might otherwise go unnoticed. For example, while a product manager might focus on market-related risks, engineers might highlight technical challenges, and customer support teams might flag potential user experience issues. This holistic approach ensures that all project aspects are considered and solutions are more robust. Promoting long-term thinking: In product development, there is often pressure to focus on short-term gains — getting a product to market quickly or delivering features to meet immediate customer demands. While these goals are important, the pre-mortem encourages teams to think beyond immediate deadlines and consider the long-term health of the product. By identifying and addressing risks early, teams can create more sustainable products that are positioned for long-term success. Pre-Mortem Nay-Sayers While pre-mortems offer significant benefits, there are several common arguments or concerns from those who may oppose using them. Here are a few points skeptics might raise: “It’s too negative.” Some opponents may argue that focusing on failure is counterproductive and could dampen team morale. They might feel that pre-mortems encourage a pessimistic mindset, which could create unnecessary anxiety and hinder creative problem-solving. “We already have risk management processes.” Organizations with established risk management frameworks may see pre-mortems as redundant. These skeptics could argue that risk identification and mitigation are already built into their development or project management processes, so adding a pre-mortem exercise is unnecessary. “It takes too much time.” Pre-mortems require dedicated time and effort, which critics might see as an obstacle in environments where teams are pressured to deliver quickly. Critics might argue they cannot afford the extra time needed to run this exercise, especially for smaller or iterative projects. “We can’t predict everything.” Some may feel that unpredictable challenges will still arise no matter how much effort teams spend in advance on trying to anticipate failures. They might argue that it’s impossible to foresee every issue and that energy should instead be focused on being adaptable when problems occur. “It’s not necessary for all projects:” Teams working on well-understood products or incremental improvements may believe a pre-mortem is overkill. They could argue that the complexity and risks involved in such projects are minimal, so a pre-mortem exercise doesn’t add enough value to justify its use. Food for Thought They can help navigate uncertainty: Quickly adapting to new information is critical. Pre-mortems prepare teams to handle unexpected shifts, whether from changes in customer needs, new competition, or evolving technology. The exercise arms teams with contingency plans, helping them stay agile and responsive. Integrate pre-mortems with Agile practices: Pre-mortems align well with Agile frameworks like Scrum. Scrum focuses on short iterations, learning from each Sprint, and delivering value incrementally. A pre-mortem before a Sprint or a significant release can complement this by surfacing risks, thus ensuring that teams are not just churning out more features but delivering the right thing in the right way. Pre-mortems build psychological safety: In many teams, people may hesitate to voice concerns due to fear of being seen as negative or disruptive. Pre-mortems actively encourage exploring what could go wrong, fostering an environment where it’s safe to challenge assumptions and offer critical feedback. This approach creates a culture of openness, where team members feel empowered to speak up about potential risks early on. Pre-mortems are cost-effective: The exercise helps prevent expensive course corrections later in the product development cycle. By identifying risks upfront, teams can avoid rework, scope creep, or technical debt, which are common causes of project delays and budget overruns. It’s not just for big projects: While pre-mortems are often associated with large-scale product launches, they can also be handy for minor features, iterative improvements, or even individual Sprints. The ability to anticipate and mitigate risks applies at any scale, making the pre-mortem a versatile tool for continuous improvement. Conclusion: Why the Pre-Mortem Should Be a Regular Practice When delivering valuable products and features, playing defense is just as critical as offense. The pre-mortem is more than just a clever brainstorming exercise — it’s a strategic tool for addressing risks before they snowball into costly mistakes. In a world where uncertainty is the norm and agility is critical, the pre-mortem provides teams with a practical framework to future-proof their work. Don’t fall into the trap of reacting to failure after the fact. Instead, harness the inversion principle to flip the script on risk and failure, transforming potential disasters into actionable insights. The pre-mortem enables teams to spot blind spots, foster psychological safety, and collaborate across functions—leading to better decision-making and more resilient products. If your team is serious about continuously delivering consistent value and thriving in complex environments, the pre-mortem should be a non-negotiable part of your product development toolbox.

By Stefan Wolpers CORE

Quality is the pillar that supports any software product. If a platform works poorly, both the business and the customers fail, as they do not get what they are looking for or satisfy their most immediate needs. That's why, as customer demands and market competitiveness increase, software teams must adapt quickly to deliver high-quality products. In this scenario, Agile practices can make an important difference and are the basis of project managers today, since they can not only improve efficiency through the Agile methodology but also promote software quality in a notable way. Keys to Agile Practices “Agile is an iterative, introspective, and adaptive project management methodology. In an Agile practice, a project is divided into subprojects. These are usually called sprints. At the end of each sprint, stakeholders and the team review their work, make adjustments for the next sprint, and iterate until complete. The goal of Agile is the constant and incremental delivery of value throughout the project, instead of doing it all at once at the end,” they explained about this methodology in a Forbes article. Agile methodologies focus on flexibility, collaboration, and continuous delivery of value. Instead of following a rigid plan, Agile teams take an iterative and incremental approach. This allows us to respond in an Agile manner to changes in requirements and market needs. But How Exactly Do These Practices Contribute To Improving Software Quality? 1. Iterative and Incremental Deliveries “Iterative delivery means that a team delivers work frequently rather than doing it all at once. Incremental means they deliver it in small packages of end-to-end functionality that is usable. After all, the only thing better than a great product is a great product that improves frequently,” they detailed on the Scrum portal, one of the most used Agile methodologies. This allows: Continuous feedback: Teams receive early and frequent feedback from end users and other stakeholders. This makes it easier to identify and fix errors early before they become costly problems. Constant improvement: Each iteration offers an opportunity to improve the product and adjust processes, allowing for a continuous focus on quality. 2. Prioritization of Requirements and Value One of the key principles of Agile is prioritizing the product backlog based on customer value. “Scrum uses value-based prioritization as one of the core principles that drives the structure and functionality of the entire Scrum framework. It benefits projects through adaptability and iterative development of the product or service. More importantly, Scrum aims to deliver a valuable product or service to the customer early and continuously,” they noted in the Scrum Study. Project managers must: Collaborate with stakeholders: Work closely with customers and other stakeholders to identify and prioritize the features that provide the most value. Adapt team focus: Ensure the team focuses on the most critical tasks that improve product quality and maximize delivered value. 3. Integrated Testing and Automation Integrating continuous testing into the development cycle is essential in Agile. Testing is accomplished through: Testing in each iteration: Testing is not reserved for the end of the development cycle. In Agile, software is tested during each sprint, allowing for early detection of defects. Test automation: Implementing automated testing tools allows for faster and more frequent testing, ensuring that new code does not break existing functionality. 4. Collaboration and Constant Communication In an Agile environment, open communication and collaboration are essential. “Agile methodologies value people and human interactions over processes and tools. Agile approaches help teams keep the focus on team members by allowing communication to occur fluidly and naturally as the need arises. And when team members can communicate freely and naturally, they can collaborate more effectively”, they detailed in a GitLab article. In this sense, among the responsibilities of project managers are: Facilitate communication between teams: Promote daily stand-ups and sprint reviews to keep all team members informed and aligned. Remove barriers: Act as facilitators to remove obstacles that may slow down the team, ensuring efficient workflow. 5. Promotion of a Culture of Continuous Improvement Agile project managers must instill a continuous improvement mindset within the team, including: Regular retrospectives: Hold retrospective meetings at the end of each sprint to reflect on what worked well and what can be improved. Adoption of best practices: Promote the adoption of techniques and tools that improve the quality of development, such as code refactoring, test-driven development (TDD), and continuous integration (CI). “Unlike waterfall project management, which is a sequential approach to project execution, continuous improvement allows you to make constant adjustments to meet changing project demands. These small adjustments and changes you make are part of the continuous improvement process,” they explained in an Atlassian article. 6. Team Empowerment In Agile, there is a strong emphasis on team empowerment. Project managers must: Delegate responsibility: Allow teams to have autonomy in making decisions related to software development and quality. Foster product ownership: Encourage team members to feel shared responsibility for the quality of the final product. Adopting and applying Agile practices is not just a matter of following a set of procedures; is a philosophy that focuses on continuous improvement, collaboration, and value delivery. For project managers, the challenge lies in leading their teams with these practices, ensuring that each development cycle not only meets customer requirements but also constantly improves software quality. Successful implementation of Agile methodologies can transform the way software is developed, providing more robust products, with fewer defects and greater customer satisfaction. As a project manager, embracing Agile can be the way to raise software quality and take your team to the next level of excellence.

It’s easy to imagine the burden that you, as a developer, can feel rushing to perform your tasks quickly, sometimes forgetting about the amount of confusion you can feel by reading and producing the code fast. This confusion can cost both time and money and have an awful impact on the project you work on. This state of confusion, which takes place when a developer faces an overwhelming amount of information and multitasking, is not an imaginary sandcastle. This mental state is called cognitive overload. Increased forgetfulness, lack of focus, hampered creative thinking and innovation, and difficulties in learning new concepts are all symptoms of cognitive overload. What can you do to reduce it and have peace of mind? Cognitive Workload: Let’s Break Down the Theory During your daily routine, and especially when reading code, you need to hold many facts in your head – it can be variables’ values and their related components, changes, version history, conditional logic, etc. However, on average, a person can hold roughly four such unconnected facts in his working memory. And, once the cognitive load crosses its barrier, you need to put a lot of effort into understanding even the easy stuff. Another example of when you can feel cognitive overload is when you face a difficult task. Imagine that you have just switched projects and need to understand the one that has over a few thousand lines. Yep, for those who are familiar with that code, it can be easy, but for those who see that code for the first time, it can be hard to understand and, let’s say, find the mistake. Also, here we can add knowledge, experience, and limitations of tools you can use in your work. Types of Cognitive Load There are three types of cognitive load developers can face: Intrinsic load that relates to the task and its complexity. For example, it takes place when you need to understand complex algorithms or the logic of some new feature within a big codebase. Extraneous load, which depends on the structure of the information or the task you get. To understand it better, imagine a poorly designed interface or a too-complicated development environment. Would it become a burden for you? Germane load, which is associated with the effort you put into creating a schema in your working memory. In other words, it’s your productive ability to pick up new skills and learn. What Are the Consequences of Cognitive Overload? Mistakes, developers’ irritation, and wariness are among the main reasons why it’s important to find the best practices to decrease cognitive load. But for hindering developers’ ability to stay innovative and creative, the cognitive load also has important business implications. They include: Decreased responsiveness as it becomes difficult for businesses to respond quickly to customer and market demands Reduced customer satisfaction as the product or services the company produces can become low-performing and, what’s worse, unreliable Security concerns as due to a lack of attentiveness, developers can make mistakes, opening the doors to unnoticed security flaws, ransomware, and other cyber attacks How To Reduce Stress and Simplify Developer Workflows That’s the question. There is no magic pill to solve this issue. Only a complex-based approach can help here – strategy and tools to help your team have an overall better developer experience and reduced cognitive load. Simplify and Refactor Your Code We have already mentioned that the complexity of the task can result in an intrinsic cognitive burden. To reduce it, you can break down your code complexity into smaller, easier-to-manage chunks. Thus, for example, if a new developer joins your team, it would be easier for him to become familiar with his work, eliminating mistakes. Improve Documentation and the Readability of the Source Code Isn’t it easy for your developers to understand the project if your code is clear and the documentation is well-organized? No doubt that yes: if information is easily accessible and understandable for your team, they will have less stress responding to issues, and, as a consequence, it will reduce their cognitive load, as they will be able to focus on the task better. Adopt Pair Programming Working together on a task, your developers can generate better ideas and share their duties. Thus, they will be able to complement each other’s knowledge and skills, learn, and reduce their germane overload due to their collective problem-solving. Adopt Platform Engineering Platform engineering can be another way to reduce cognitive load. In this case, platform engineers work directly with developers, providing them with the necessary resources and tools to increase efficiency and production, and, as a result, build more reliable products much faster. Here is an example: platform engineers can create self-service tools and workflows for developers, including infrastructure provisioning tools, developer portals, continuous integration, and continuous delivery (CI/CD) pipelines. What’s more, they can cooperate on creating and maintaining best practices for software development and delivery. Automate Tasks, Especially Repetitive Ones The better your team is equipped, the more reliable code they produce. Thus, it’s important to automate all possible tasks, allowing your team to concentrate on their core duties and more important issues. For that reason, you can use different tools, depending on which tasks are better for your team to automate. Motivate Your Developers To Learn The culture of continuous learning is one of the best ways to eliminate germane cognitive load. Learning and self-development will provide your developers with the necessary frameworks to understand complex data easier and more effectively. Better Backup Strategy, Lower Cognitive Load The impact of cognitive load can be drastic. Moreover, it threatens the security of the source code. That’s why, while you are looking for ways to reduce the cognitive overload of your team of developers and optimize their workflow, you should also pay attention to security measures that can help. One of the most effective ways to do this is to have an effective backup strategy in place, as it can give your team peace of mind knowing that even if they make a mistake, their data is protected against data loss or any other risks, including infrastructure outages, hardware failures, natural disasters, or malicious attacks. An effective backup strategy can help to minimize the risk of data loss and ensure that data is always available. What’s more, a well-built backup strategy can help reduce the amount of time your developers spend on manually backing up data – writing backup scripts, checking if backup scripts are recoverable, and writing recovery scripts, which is not only a lot of work, but also a responsibility burden. By automating the backup process, developers can save time and focus on more important tasks. Finally, an effective backup strategy can help reduce the amount of time spent troubleshooting. If data is lost or corrupted, having a backup strategy with restore and Disaster Recovery Technology can help you quickly and easily retrieve your data, leaving no time for your developer’s team to worry. Tips for Developing an Effective Backup Strategy Now let’s go through the features that are necessary for a reliable and comprehensive backup strategy: Automate the backup process, as it will help your team save time and ensure that all the critical source code data is always backed up. Ensure that your backup plan covers all your repositories and metadata because in this case, you will be sure that no single line of your source code is lost in the event of failure. Follow the 3-2-1 backup rule, when you keep at least 3 of your copies in at least 2 different storage locations, one of which is offline. Thus, even if one of your backups fails to run, you always have a few other copies. Unlimited retention for your DevOps data, which ensures that your source code is accessible from any point in time Monitoring center, which will simplify monitoring of backup and restore performance, leaving more time for your developers to do their core duties; Moreover, it’s nice if your backup tool gives you a full picture of backup procedures via Slack, email notifications, advanced audit logs, and tasks. Easy management, which will permit you to set up roles and responsibilities over backup performance to your team Ransomware protection Restore and Disaster Recovery possibilities to bring peace of mind that all your critical data is accessible and recoverable should any event of disaster take place. Conclusion By automating the process, protecting against data loss, and reducing the amount of time spent troubleshooting, an effective backup strategy can help to make life easier for developers. What’s more, by reducing the cognitive load connected to source code and data protection, developers can channel their energy into creative problem-solving, collaboration, and innovation. Implementing a reliable backup strategy is not just a precautionary measure, it’s an investment in the mental well-being and productivity of your development team.

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.

In this article, I will discuss: The concept of Deep Work Why it is important in this day and age What are some of the unique challenges that Site Reliability Engineers face that make it hard to do Deep Work in their field? Some strategies that Site Reliability Engineering teams can employ to overcome these unique challenges and create an environment for Deep Work for SREs What Is Deep Work? Let's take a look at what Deep Work is. The concept of Deep Work was introduced by Cal Newport in his book called, "Deep Work: Rules for Focused Success in Distracted World." In his book, Cal Newport defines Deep Work to be the act of focusing without distraction on a cognitively demanding task. The opposite of Deep Work is Shallow Work, which Cal Newport defines as logistical-style tasks that can be performed while distracted, like work coordination and communication tasks that are easy to replicate. Why Is Deep Work Important? Firstly, Deep Work is meaningful and satisfying. Based on a recent Gallup Survey, employee engagement in the United States has hit a record low due to less clarity and satisfaction with their organizations. Deep Work can help solve this problem. Secondly, Deep Work can pave the path to a Flow State. The research found that the Flow State leads to happiness. Finally, Deep Work is rewarding. Doing cognitively-demanding work brings value to teams and organizations which in turn will lead to promotions and financial rewards for the individual doing the Deep Work. As Cal Newport says, "A deep life is a good life." Now, let's look at some of the activities that are cognitively demanding for SREs, the activities that can be considered Shallow activities, and some strategies that SRE teams can employ to promote Deep Work within the SRE teams. What Are Some Cognitively Demanding Tasks for SREs? The following are some of the cognitively demanding tasks that SRE teams can perform to have a greater impact on the organizations: Automation and building services: Developing good automation to eliminate toil, improve the efficiency of managing infrastructure, and reduce costs is a cognitively demanding task. Contributing to the codebases that backend teams develop can also be a good opportunity for SREs and is a cognitively demanding task. Improving observability: Another cognitively demanding task for Site Reliability Engineers is improving the observability of the systems. This can be done through designing and creating usable dashboards, tuning alerts to improve signal-to-noise ratio, instrumenting codebases to emit useful metrics, etc. Debugging and troubleshooting difficult issues impacting production systems: Troubleshooting difficult issues affecting production systems availability under time pressure is another cognitively demanding task. Improving processes: Improving processes such as the change management process, incident management process, etc. to improve the overall efficiency of the team, and improving SLOs can be another cognitively demanding task. Improving documentation: Writing good documentation can be impactful and requires focus to get it done. A few examples of good documentation are usable troubleshooting guides, Standard Operating Procedures, architectural diagrams, etc. Learning new technical skills: Continuous learning is key to becoming better at an SRE job. Learning new technical skills and keeping up with the latest technology trends such as Generative AI, etc. is cognitively demanding as well. What Challenges Do SREs Face To Perform Deep Work? The following are some shallow tasks that SREs need to do to run the business that make it difficult for them to do Deep Work: 1. Deployments and Upgrades These are essential activities for the business but tend to be repetitive in nature. Depending on the level of automation that exists within the team, SREs spend some amount of time on these activities. 2. Answering Questions of Other Engineers Randomization of SRE team members by random questions from other teams can be helpful since SRE teams tend to have a deeper knowledge of production systems and infrastructure. 3. Production Access Requests In many teams, access to production systems is restricted only to the SRE team to maintain the stability of the production environments. Members of teams such as backend engineering and data engineering teams may interrupt SREs to get information from production systems for various purposes such as debugging issues, etc. 4. Randomization Due to On-Call and Production Issues SREs tend to have end-to-end knowledge about the production systems and often may be pulled into various on-call issues even when the SRE is not in the current on-call rotation. This takes time away from working on meaningful projects. 5. Meetings There is a lot of overhead with meetings. With SRE roles, sometimes a lot of people join calls that try to troubleshoot issues, and these calls tend to be very long where a lot of engineers just act as bystanders for extended periods of time. 6. Answer Emails and Replying to Teams/Slack Chats This is a common activity for most of the people working in the knowledge economy, and SREs are not immune to it. Replying to emails and chats constantly randomizes an SRE's time and takes their attention away from important work. What Strategies Can SREs Employ To Facilitate Deep Work? Now let's look at some of the strategies that SRE teams can employ to minimize time spent on Shallow work and spend that time on Deep Work: 1. Invest in Automation SRE teams should prioritize investing time in automation to eliminate toil and reduce operational burden with various activities such as deployments, upgrades, etc. Creating robust Continuous Integration and Continuous Deployment pipelines with built-in automated verifications will reduce time spent on these activities. The goal should be to give required tools for development teams to do self-service with upgrades and deployments. SRE team management should plan projects so that proper resources are allocated for these kinds of projects. 2. Build Just-In-Time Access Systems Just-in-time access systems with proper auditing trail and approval processes can help give proper access to production environments for people outside SRE teams, and thus, help SRE teams not to spend time on providing shadow access to others and focus on Deep Work. 3. Proactively Plan for Projects SRE teams can have proper Project Management in place to prioritize important work such as improving the observability of critical production services. 4. Sharing the On-Call Load With R&D and Backend Engineering Teams Sharing on-call load with backend engineering teams while letting SRE teams focus on improving the tooling, and documentation, and training others on how to effectively handle on-call issues would help with this as well. 5. Follow Efficient On-Call Rotations and Incident Management Processes Following efficient on-call rotations where only the responsible on-call engineers during that week handle most of the on-call issues lets other engineers focus on dedicated projects and makes Deep Work possible for the rest of the team. Having clear and easy-to-follow troubleshooting guides would aid with this purpose. 6. Create Time Blocks to Focus on Important Projects On a personal level, individual SRE team members can block time on the calendar to focus on working on important projects to avoid randomization. 7. Providing Time and Resources for Continuous Learning Giving time to SRE team members to learn and explore new technologies and the freedom to implement the technologies to solve reliability problems is a great way to facilitate learning. Also providing subscriptions to online learning services and books would be a great idea. 8. Allow SREs To Work on Projects of Their Choice Allowing SRE team members to work on projects of their choice would be a great way to encourage them to do Deep Work. For example, writing features used by end users, experimenting with a new piece of technology, and working on a different team short team are some of the ways to implement this idea. Google famously allowed all their employees to spend 20% of their time on the projects of their choice. Implementing such a policy would be a great way to encourage Deep Work. Conclusion By following the strategies discussed in this article, Site Reliability Engineers can aim to perform Deep Work and achieve happiness, satisfaction, and rewarding work while having a greater impact on their organizations.

A (long) time ago, my first job consisted of implementing workflows using the Staffware engine. In short, a workflow comprises tasks; an automated task delegates to code, while a manual task requires somebody to do something and mark it as done. Then, it proceeds to the next task — or tasks. Here's a sample workflow: The above diagram uses the Business Process Model and Notation. You can now design your workflow using BPMN and run it with compatible workflow engines. Time has passed. Staffware is now part of Tibco. I didn't use workflow engines in later jobs. Years ago, I started to automate my conference submission process. I documented it in parallel. Since then, I changed the infrastructure on which I run the software. This post takes you through the journey of how I leveraged this change and updated the software accordingly, showcasing the evolution of my approach. Generalities I started on Heroku with the free plan, which no longer exists. I found that the idea was pretty brilliant at the time. The offering was based on dynos, something akin to containers. You could have a single one for free; when it was not used for some time, the platform switched it off, and it would spin a new one again when receiving an HTTP request. I believe it was one of the earliest serverless offerings. In addition, I developed a Spring Boot application with Kotlin based on the Camunda platform. Camunda is a workflow engine. One of the key advantages of workflow engines is their ability to store the state of a particular instance, providing a comprehensive view of the process. For example, in the above diagram, the first task, labeled "Request Purchase," would store the requester's identity and the requested item (or service) references. The Purchase Department can examine the details of the requested item in the task after. The usual storage approach is to rely on a database. The Initial Design At the time, Heroku didn't provide free storage dyno. However, I had to design my initial workflow around this limitation, which posed its own set of challenges. I couldn't store anything permanently, so every run had to be self-contained. My fallback option was to run in memory with the help of H2. Here is my initial workflow in all its glory: As a reminder, everything starts from Trello. When I move a card from one lane to another, Trello sends a request to a previously registered webhook. As you can expect, the hook is part of my app and starts the above workflow. The first task is the most important one: it evaluates the end state from the event payload of the webhook request. The assumption is that the start state is always Backlog. Because of the lack of storage, I designed the workflow to execute and finish in one run. The evaluation task stores the end state as a BPMN variable for later consumption. After the second task extracts the conference from the Trello webhook payload, the flow evaluates the variable: it forwards the flow to the state-related subprocess depending on its value. Two things happened with time: Salesforce bought Heroku and canceled its free plan. At the same time, Scaleway offered their own free plan for startups. Their Serverless Container is similar to Heroku's - nodes start when the app receives a request. I decided to migrate from Heroku to Scaleway. You can read about my first evaluation of Scaleway. I migrated from H2 to the free Cockroach Cloud plan Refactoring to a New Design With persistent storage, I could think about the problems of my existing workflow. First, the only transition available was from the Backlog to another list, i.e., Abandoned, Refused, or Accepted. The thing is, I wanted to account for additional less-common transitions; for example, the talk was accepted but could be later abandoned for different reasons. With the in-place design, I would have to compute the transition, not only the target list. Next, I created tasks to extract data. It was not only unnecessary, it was bad design. Finally, I used subprocesses for grouping. While not an issue per se, the semantics was wrong. With persistent storage, we can pause a process instance after a task and resume the process later. For this, we rely on messages in BPMN parlance. A task can flow to a message event. When the task finishes, the process waits until it receives the message. When it happens, the flow process resumes. If you can send different message types, an event-based gateway helps forward the flow to the correct next step. Yet, the devil lurks in the details: any instance can receive the message, but only one is relevant — the one of the Trello card. Camunda to the rescue: we can send a business key, i.e., the Trello card ID, along with the message. Note that if the engine finds no matching instance, it creates a new one. Messages can trigger start events as well as regular ones. Here's my workflow design: For example, imagine a Trello hook that translates to an Abandoned message. If there's no instance associated with the card, the engine creates a new instance and sends the Abandoned message, which: Start with the flow located at the lower left Ticks the due date on the Trello card Finishes the flow If it finds an existing instance, it looks at its current state: it can be either Submitted or Accepted. Depending on the state, it continues the flow. Conclusion In this post, I explained how I first limited my usage of BPMN and then unlocked its true power when I benefited from persistent storage. However, I didn't move from one to the other in one step. My history involves around more than twenty versions. While Camunda keeps older versions by design, I didn't bother with my code. When I move them around, it will fail when handling cards that were already beyond Backlog. Code needs to account for different versions of existing process instances for regular projects. I'm okay with some manual steps until every card previously created is done. To Go Further Business Process Model and Notation Camunda My evaluation of the Scaleway Cloud provider

By Nicolas Fränkel CORE

Effective conflict management is essential for technology teams to maintain a productive and innovative work environment. Google's Project Aristotle, an internal study aimed at understanding the factors that contribute to successful teams, highlighted the importance of psychological safety and open communication in fostering collaboration and navigating disagreements among team members. This article will explore conflict management strategies inspired by Google's Project Aristotle and additional data points, using a use case to illustrate their application in real-life scenarios. Conflict Management Strategies 1. Embrace Diverse Perspectives Technology teams often consist of individuals with varied backgrounds, expertise, and perspectives. Encourage team members to appreciate and learn from these differences, as diverse viewpoints can lead to more creative and innovative solutions. 2. Foster Psychological Safety Create an environment where team members feel comfortable expressing their thoughts, concerns, and ideas without fear of ridicule or retribution. Psychological safety promotes constructive feedback, open communication, and effective conflict resolution. 3. Encourage Collaboration Organize joint brainstorming sessions and workshops to encourage collaboration between team members with different expertise. This cooperative approach can help build trust and rapport among team members, making it easier to navigate conflicts when they occur. 4. Utilize Effective Communication Tools Leverage various communication tools, such as instant messaging, video conferencing, and project management software, to facilitate seamless communication among team members. This can help prevent misunderstandings and ensure that everyone stays informed and engaged. 5. Offer Training in Soft Skills In addition to technical expertise, soft skills such as communication, empathy, and emotional intelligence are crucial for effective conflict management in technology teams. Provide training and resources to help team members develop these essential interpersonal skills. 6. Conduct Regular Retrospectives Hold regular retrospectives to reflect on project progress, team dynamics, and potential areas of improvement. These meetings provide an opportunity for team members to openly discuss any conflicts or challenges they have encountered and collaborate on solutions. 7. Adapt To Change and Manage Expectations Technology projects often involve rapidly changing requirements and priorities. Help team members adapt to change by setting realistic expectations, being transparent about project status, and providing support during transitions. 8. Promote Work-Life Balance Encourage team members to maintain a healthy work-life balance, as excessive stress and burnout can exacerbate conflicts. Support flexible work arrangements and create a culture that values downtime and self-care. Use Case: A Software Development Team at Google The Google Maps team consists of engineers, product managers, and UX designers with diverse backgrounds and expertise. As the project progresses, a conflict arises between engineers and UX designers over the implementation of a particular feature. The engineers argue that the proposed design is too resource-intensive, while the UX designers insist that it is essential for a seamless user experience. By applying the conflict management strategies mentioned above, the Google Maps team can effectively address this conflict: The team leader promotes open discussion and values each team member's unique perspective, leading to more innovative ideas and solutions. The team leader ensures that all team members feel comfortable expressing their concerns and ideas, creating an environment where constructive feedback and open communication are valued. The team leader organizes a joint brainstorming session between the engineers and UX designers to explore alternative solutions that meet both the user experience goals and the technical constraints. The team uses Google Workspace tools like Google Meet, Google Chat, and Google Docs to facilitate seamless communication, collaboration, and documentation of decisions. Google provides workshops and resources on effective communication, negotiation, and problem-solving, helping team members develop the interpersonal skills needed to navigate conflicts successfully. After resolving the conflict, the team holds a retrospective meeting to reflect on the situation, discuss lessons learned, and identify ways to prevent similar conflicts in the future. The team leader communicates any changes in project requirements or priorities clearly, helping team members adapt and manage their expectations. The company supports flexible work arrangements and encourages team members to maintain a healthy work-life balance, reducing stress and potential conflicts. Conclusion By applying the lessons learned from Google's Project Aristotle and incorporating additional data points, technology teams can effectively manage conflicts and foster a harmonious and productive work environment. Embracing diverse perspectives, fostering psychological safety, encouraging collaboration, utilizing communication tools, offering soft skills training, conducting regular retrospectives, adapting to change, and promoting work-life balance are key strategies that empower team members to navigate and resolve conflicts effectively. With a proactive approach to conflict management, technology teams can become more engaged, satisfied, and high-performing.

By Arun Pandey CORE

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.

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