Manveer Chawla

Managing risks as an Engineering Manager

Risk Management word cloud

As a Manager, you are given a portfolio of products and a set of resources. In return, you are tasked to deliver results for the Organization. A key part of the responsibility is to manage risks while executing on these initiatives. Managing risks is hard, it is particularly hard for a software product since it requires expertise in underlying technology. Thus Engineering Managers are expected to provide leadership within Organization and manage risks for their products.

Risks in a project

We are always making tradeoffs, whether we acknowledge them or not. And there are various risks associated with them, whether building a new product or a new feature or fixing a bug. Over a period of years, I have built this framework to reason about various risks and how to manage them. Everytime I embark on a new initiative I perform this premortem to analyze all the risks and make a plan to mitigate them.

Technical risk

This relates to the quality and operational risks in the project. The software may not work as expected, or may have unintended impact on the rest of the infrastructure, or may not be able to handle production scale. The goal here is to identify different failure modes and have a mitigation plan to resolve the failure. It should be able to handle partial or complete failures. Some strategies for mitigation are to

  • Run tests (preferably automated)
  • Build failsafes like taking backups, having redundancy, etc
  • Build a kill switch or use feature flags
  • Perform staged rollouts

Product risk

This relates to the product market fit and usability risk for the product. This is relevant for both internal and external products. The goal is to ensure the Total Addressable Market is big enough, the product is solving a real customer need and they are able to use it when shipped. Some strategies for mitigation are to

  • Talk to users to collect feedback
  • Shorten the feedback loop. A Design Sprint is another useful tool that encapsulates some of these principles
  • Perform competitive analysis

Resource risk

This relates to different resources needed to deliver the product. It includes people, talent, time, hardware, software and information, The goal is to plan ahead and get the required resources. Some strategies for mitigation are to

  • Create a project plan with incremental milestones
  • Hire (or borrow or contract) people with required skills
  • Setup training to level up employees
  • Assign roles and responsibilities
  • Create process to track progress

Dependency risk

This relates to how the product may interact with other products or systems, and changes required to be done by other team(s) to support the interaction. The organizational dependency adds the complexity, as these teams would have their own priorities and commitments. The goal is to make sure required changes are identified and delivered along with the product. Some strategies for mitigation are to

  • Identify the list of products shipped by the organization to customers and analyze how the new product will interact with them
  • Get buy-in from the stakeholders to deliver the required changes
  • Periodically check-in with the stakeholder to track the progress
  • Regularly communicate the progress to all stakeholders
  • Tests interaction with these systems to detect gaps

Pricing risk

This relates to the impact a product may have on the top line and bottom line. The goal here is to ensure it is profitable for the business to build and offer the product, while still being able to acquire customers. Some strategies for mitigation are to

  • Build a cost model for offering the product to the customers to analyze the impact on the bottom line
  • Analyze the price for competitive products

Closing thoughts

It is useful to perform a premortem to analyze the risks at the beginning of the project, however for long running projects it is important to periodically reassess them as new information is acquired. Lastly, there is the 80/20 rule for applying this framework. This means 80% of the products in your portfolio will not require such a thorough analysis, hence it is important to identify the 20% that do and spend the effort wisely on them.