Team Management

People often ask me for advice when they move to a manager of managers role. This post covers ten things to consider. I’ll describe a number of things that surprised me, some skills to focus on building, and some tips for navigating this phase of your career. Being a Director Is a Very Different Job First of all, the move to being a director was a bigger change for me than I expected. I thought managing managers would be similar to managing engineers. That was naive. The shift wasn’t quite as big as moving into management. But it was close. Being a Half Director Isn’t the Preparation You May Think It Is As a senior manager, I started to transition into a manager of managers role. But I did so in a hybrid way: managing a team directly, and managing another manager at the same time. I thought this meant that I understood the job of managing another manager. I did learn a lot, but it wasn’t the preparation I thought it would be. Why? The skills to manage that manager was new, so I did the job in a limited way. Only when my role switched to fully managing other managers did I have enough ability to focus on the job? It was then that I realized how little I actually knew about that work, and started to grow at a faster pace. You’ll Do Most of Your Work Through Others One of the larger shifts in the nature of your work is that Directors do most of their work through other people. You may think you’re doing work through other people when you’re managing engineers as a front-line manager. But Directors have to operate at a much higher level of indirection. A consequence of this is that your weekly meeting with your managers, and your 1-1s with them, become the most important meetings of your week. Consider lengthening your 1-1s with them to an hour, and make them weekly. And spend serious time planning your management meetings and 1-1s. They are where you should be doing most of your work. Operating with so much indirection can be an adjustment. Most successful managers have probably been successful largely through their direct efforts. They’ve managed projects well, or hired well, or made improvements to their team. When you’re a Director, you’re usually working through someone else who is doing the work. Suddenly your success is based on how well your managers are running their projects. Your success is based on how well they hire. Your success is based on the improvements they make on your team. This leads to a few common pitfalls. One is the overinvolved Director, who doesn’t make space for their managers to do the work themselves. One sign this is happening is if you’re in all the same meetings as your manager. The second is the involved Director, who views their role as hiring the right people and supporting them. This is similar to the shit shield school of management. Instead, I encourage you to think about your level of involvement as something you flex depending on the circumstances. Your goal is to be less involved, but it should depend on the level of expertise of the manager in this particular area, and the complexity and challenge of the situation they’re facing. When a situation is challenging for a manager, you might be more proscriptive, giving them a pattern to follow. You might review their plans and offer more feedback. You should interact more frequently, and talk through the actions they plan to take. A Lot of Your Job Is Training Managers This flexing of your level of attention is an important part of your role as Director. And it leads to the next thing to be aware of as a Director: your role is to train your management team. Ideally, any of your managers should be able to step into your shoes, and do any part of your role. And even if they can’t do so, your job is to prepare at least one of them to do so. To understand this topic, I first recommend you read my post on Completed Staff Work. Pay special attention to the end, where I review Marquet’s Ladder of Leadership. The way I like to look at my management team is that they all have varying levels of skills in different areas. Sometimes their skills will exceed my own in certain areas! But my role is to help them develop their skills as rapidly as possible. Part of this is that the more skilled they are, the more autonomously they can operate. This is at the heart of a scalable organization. If all your managers rely on you for everything, you have an ineffective organization. So your job is to create an increasingly autonomous and skilled organization. One that is able to produce good results independently. To do this, you need to be expanding their skill set, and creating the right environment for them to thrive. Coach and develop them to build their skills. Biggest Skill to Learn: Sensing Your Organization The biggest surprise for me when I moved to a pure manager of managers role was how little I knew what was going on. It was like someone had turned off all the lights. I couldn’t see anything that was happening any more. You may find the information vacuum unsettling. You’re simultaneously put in a position where your job is to make things better, but you have much worse information about where the problems are. I see some Directors become destructive to their organizations at this point. They rely on their gut and pride themselves on making decisions without full information. This can work sometimes, but it can also result in problems. It’s like a doctor that doesn’t diagnose the disease and instead starts filling you with random drugs and starts surgery in random parts of your body. Correctly diagnosing and understanding the cause of things is essential. You need to build a way to understand what is happening in your organization. You need to set up observability of your organization, so you’ll know if things are going off the rails. Pay a lot of attention to this. It gives you the ability to support your managers, and it provides opportunities for intervention. A few things you might try: Look for meetings that give you signals that things are going well, or not going well. I found demos to be a particularly rich source of information, for example. Do skip levels 1-1s, to get a random sense of how things are going, and to establish connections throughout your organization. Collect metrics from your managers, so you can have conversations about trends or things that seem to be going off track. Look at the information tools can give you. Stats on reliability, how often people are paged, product usage metrics and analytics tools can help fill in your picture of how things are going. One trap to be wary of is that your need for information may entice you to ask your managers for information. You’ll probably need information frequently enough that you can be a source of annoyance to them. Consider adding some structure around your information needs. Think about what you really need to know each week, and ask your managers to push it to you, instead of pulling it from them all the time. You’ll Need a New Perspective One question to ask yourself is where you can be helpful to the organization. What are things you can do that nobody else can do? One thing you do more as a Director is to plan further into the future. It would be best if you had a higher-level perspective on how your organization’s work fits into the broader offering of the company. This perspective is something you can use to shape the direction your organization heads and is something your managers cannot usually do. The skill to learn here is outlined in my post: Leaders make their own problems. I recommend looking at that post carefully. You can also look at this post on upstream thinking, as I think it outlines some of the mindset required as a Director. You Should Focus On Systems A weird thing about being a Director is that you operate more at a meta-level. What I mean by that is that instead of directly tinkering with a team, you’re working with a system of teams. Your focus should be shifting to be more about the patterns of things, than the details themselves. This may come naturally to the rare people who tend to be systems thinkers. For everyone else, this is a skill to build. My suggestion is to always be operating at two levels: solving both the immediate problem and looking at the level of abstraction above that. For example, if there is a project that is going off the rails, you should be thinking about how to help with that. But you should also think about what your playbook is for off-the-rails projects. Or how to notice these projects earlier. Or how to systematically reduce the prevalence of this type of project. You also should think about ways you can influence the whole system. Your toolkit is different because you’re operating at a systems level – at an organizational level. A few suggestions: You are in a unique position to offer clarity. You can simplify things for people. You can allow them to focus on fewer things. This is almost always a helpful thing for you to be doing, so pay attention to how you can both simplify things in your own mind, but also how to communicate them. You’re also in a unique position to offer context. You will have a lot more context than you used to because you’ll be interacting with higher levels of leadership than you did in the past. Think of that context sharing as a service you offer your organization. \ Constraints are a tool that you may wield more as a Director. For example, you can make simple rules for teams that help nudge them in the right direction. An example? Teams can only have a project or two they work on at a time. Don’t use over-use constraints as a tool, but sometimes it can be helpful to ask yourself: if I could only do one thing right now, what would have the biggest impact? You should also familiarize yourself with the levers of coordination models. These are patterns in the way that humans work together in groups to be effective. You’ll need to learn how to organize groups of people, do reorganizations, and so on. Some of your instincts may be untrustworthy. For example, when deciding whether to organize a team based on a skillset or around a product area, you may have suspicions about the best way to do it. But most likely, you have no idea the kinds of tradeoffs you’re dealing with. This leads to my next point. Get Support and Mentorship Many managers gradually reduce the amount of support and mentorship they receive as they go up the hierarchy. I think they do this because they’re expected to be experts. This is foolish. As you change roles and move through different parts of the organization, your skills will need to grow. So seek out people who can mentor you. Seek out peers that can give you feedback. Start your own Mini-M support group for Directors. Contact me or another experienced leader to advise or coach you. Read books and subscribe to newsletters that stretch your thinking. Beware the Distortions of Power Another thing you need to be aware of is that the higher you go in an organization, the more there is an invisible distortion field around you. It affects how people interact with you, and the information you see from your environment. This can have a harmful impact on your ability to understand the true situation in your organization. It requires a specific set of skills to counter. Without doing so, you’ll be operating in lala land, unaware of the problems you’re creating. As a Director, you’re going to start getting the first taste of this, so be on the lookout and start building your habits early. You’re Judged by the Difference You Make in Your Organization To close, I’d like to leave you with my mental model for how you can assess yourself as a Director. You are judged by the output of your organization. And specifically, you’re judged by the difference you make in the organization. What do you make better? How do you improve things? What is the diff you apply to that organization?

With the SaaS market expected to be worth $195 billion US dollars in 2023, the demand for product managers is only set to grow. But why are product managers so instrumental to SaaS companies? How do they contribute to product success, and what does it take to excel in the product management space? What Is SaaS Product Management? Software as a service (SaaS) product management is the end-to-end process of planning, developing, and scaling software products that are delivered to customers as a service over the internet rather than as a one-time purchase. SaaS product managers work closely with engineering, design, marketing, and analytics teams to guide a product through its entire lifecycle. However, unlike project managers, they aren't responsible for coordinating day-to-day product development activities. Instead, they will focus on shaping the product vision, designing a strategic plan, communicating the value proposition, and monitoring product health. SaaS vs. Non-SaaS Product Management There are some key differences between the workloads and approaches of SaaS product managers and traditional software or hardware product managers. First, the latter typically have to grapple with wider development scope. However, if we compare a product like Fitbit to Strava, it's fair to say that Fitbit PDMs have a bit more on their plates; they must deliver a sleek and highly-functional physical product to users as a full-featured fitness app. Secondly, SaaS product managers are more likely to leverage agile methodologies (e.g., the Lean Startup model or Scrum) since continuous delivery is standard practice in this domain. SaaS software is typically updated as soon as there is a change. Meanwhile, updates to classic software are less regular. Changes are usually bundled into a major or minor version update. It's also tricky and time-consuming to iterate on a hardware product. Updates take much longer to be rolled out as there are more moving parts to consider; certain malfunctions can't be fixed with a software patch. Now, let's dive into the skills that SaaS product managers need to succeed in this career. Key Skills for SaaS Product Managers Leadership Product managers are natural leaders. They trust the expertise of their team/peers, drive positive change within the organization, and inspire others to do their best. At Railsware, we value product managers who lead by example. They should be willing to delegate responsibility, get hands-on when appropriate, and prioritize shared success over personal gain. T-shaped It's not enough to be skilled at managing processes and people. Product managers should be proficient in one discipline (data analysis, for instance) yet capable of contributing to activities in other departments. For example, they can create rudimentary product designs in Figma, participate in marketing ideation sessions, navigate AWS payment infrastructure, write spreadsheet formulas to analyze data, or even write basic code. Having a robust set of technical and soft skills – and being a fast learner – are highly desirable traits. Analytical Thinking As analytical thinkers, SaaS product managers constantly use data for decision-making. They like to think outside the box and aren't afraid to challenge their own ideas or those of others. They can also analyze a problem from multiple angles, i.e., SaaS PDMs should be able to put themselves in customers' or stakeholders' shoes and spot relationships between seemingly unrelated issues. Complex Problem-Solving SaaS product managers use a combination of data, research, team input, and experience to develop innovative solutions. They are good at breaking down problems into smaller pieces and creating a step-by-step plan on how to investigate and solve them. They're also open to adapting their plans in response to new information they encounter along the way. Decision-Making SaaS Product managers must be strong decision-makers since, often; the buck stops with them. They must be able to make time-critical decisions even when they only have limited information at hand. Regarding high-level decision-making, product managers shouldn't be afraid to leverage frameworks to dive deeper into the context, invite feedback from stakeholders/knowledge-holders, develop solution variations, and prioritize them. SaaS Product Manager Responsibilities Here are some of a SaaS product manager's core responsibilities. Shaping the Product Vision and Strategy Product managers are tasked with determining the product vision. They accomplish this by running product discovery sessions, consulting with subject matter experts, utilizing agile startup frameworks (such as Lean Startup or Product-Market Fit), performing competitive analyses, and conducting market and customer research. Once the vision has been defined, SaaS PDMs are charged with crafting a product strategy that takes it from concept to reality. In addition to building a product roadmap that supports the initial phases of product development, they will also develop a strategic plan for future growth (more on that later). So, it goes without saying that product managers are responsible for aligning all departments to the product vision and communicating it to stakeholders. They will also be tasked with modifying the vision and/or strategy throughout the product lifecycle. Collaborating With Cross-Functional Teams Essentially, product managers are the glue that binds cross-functional teams together. On any given week, they will liaise with several members of the engineering, marketing, design, or data analytics departments to share expertise, answer tricky questions, communicate the product strategy, and help investigate or resolve any issues that have cropped up. For instance, when we are working on a product website redesign, the product manager will coordinate efforts between departments to ensure a cohesive end result. For example, they may collaborate with software engineers to create user stories, with designers to tweak UX flows, and with marketing experts to develop a content strategy. "Product managers are sort of like spiders at the center of a product ‘web.’ They collect information from all corners of that web — engineering, marketing, design — and use those insights to shape the product vision, design new features, or solve complex problems." — Sergiy Korolov (Managing Director) Conducting Customer Research and User Testing SaaS product managers are responsible for conducting in-depth market research and coordinating user testing. They will gather information on market trends, carry out competitive analyses, and study customer behavior. Armed with that knowledge, SaaS product managers may run ideation sessions, design user surveys, build buyer personas, or prepare materials for customer development interviews. They will also take the lead in those interviews and ensure that all research/test findings (cust dev or otherwise) are carefully recorded and synthesized. Identifying and Creating Opportunities A core aspect of the SaaS product manager role is identifying areas for product improvement and growth. They should keep an eye on industry trends and evaluate which ones are worth implementing (for instance, whether or not it makes sense to integrate AI into the product). Whether it's by running additional product discovery sessions or analyzing the activities of competitors, product managers should constantly seek out new ways to add value to the product and attract new customers. Now that we've explained the intricacies of the role let's dig deeper into some of SaaS product management's most crucial concepts and processes. Understanding the Product Lifecycle Stages The product lifecycle can be defined as a series of consecutive stages that the product moves through, from inception to eventual decline. It's an important concept in product management because the manager role typically evolves in tandem with the product's journey through the cycle. The traditional lifecycle view has four stages: Introduction, Growth, Maturity, and Decline. However, we've adapted the cycle length based on our own experience in product building. It goes something like this: New Product Development is when the product goes through the conceptual and testing stages: ideation, development, and validation. The introduction is when the product is launched on the market. Growth is when the product establishes its market position and brings profits. Maturity or Stabilization is when the product stabilizes on the market and has the highest sales volumes. The decline is when the product reaches the extent of its growth and begins to fail. Afterlife is what happens after the product dies. There are a few different scenarios – it can immediately die, inspire a new product idea, or simply become a relic. Here's a visualization of the lifecycle: What to Remember About the Product Lifecycle The lifecycle is simply a guideline and not a guaranteed forecast. There is no predicting when your product will pass through the growth, maturity, and decline stages – for some SaaS companies; it could all happen within a year of product launch; for others, it could take decades. On the other hand, many products die right after their introduction. Therefore, product managers must proceed cautiously when making decisions or forecasts based on the product's position in the cycle. The early stages are the most important—namely, New Product Development and Introduction. Of course, when your product is built on a solid foundation, it's more likely to withstand any challenges that come its way. Spend adequate time testing and iterating on your solution; listen to customer feedback and prioritize new features. Rushing to market with an unvalidated product idea could prevent you from ever reaching the growth stage. There is no such thing as infinite growth. Every product will reach the limits of success at some point and enter a period of decline. However, this is where product managers can work their magic. They are responsible for creating a new value proposition and finding innovative ways to pivot. Countless external factors can affect the product lifecycle. Be it new scientific discoveries, natural disasters, economic instability, or political unrest – there are numerous external factors that can disrupt a smooth lifecycle. Sure, these things are out of a product manager's control. But you still need to be aware of the unwanted impact they can have on your SaaS company in general. Leadership in Product Management In product management, there's more to being a leader than simply defining tasks, delegating them, and overseeing their execution. In our view, it's all about finding the balance between authority, responsibility, and accountability. So, what do we mean by that? Let's start with a brief explanation of each term: Authority is about making decisions, telling people what has to be done, and clearly defining the task that is assigned. Responsibility refers to the obligation to perform assigned tasks. Accountability is accepting responsibility (in relation to job completion) and taking personal answerability for results. An imbalance between these three interrelated components can lead to serious communication problems and team mistrust. For instance, if a product manager has a lot of authority but little accountability, then they probably micromanage and don't have the respect of their teammates. If a PDM has lots of responsibility but rarely exerts authority, then they probably struggle to delegate tasks and prioritize their own workload. To help strike this balance, we take a couple of different approaches: horizontal processes (holacracy) and an adapted RASCI model (RatSClur). In a nutshell, holacracy is a type of flat organization where teams self-organize instead of relying on orders from managers. Authority and decision-making power are distributed amongst the team, and no fixed roles exist. At Railsware, roles are taken rather than assigned. Meanwhile, RatSClur is a framework for defining those roles. It helps us keep track of who's responsible for what across various projects. Here's a breakdown of what the roles mean and where product managers fit in: DESCRIPTION EXAMPLE Responsible (R) The person who takes direct responsibility for the results no matter what blockers they face. Product Manager Lead Engineer Temporary Lead Approver (A) The person who helps the Responsible and the team to make the right choice. Is accountable for the overall outcome. Has limited hands-on involvement. Liaison Account Manager Managing Director CEO Product Manager Team (t) Does the recurrent work, keeps themselves up to date, proactively contributes to the vision, executes humbly, and stays on track. Project Manager Engineer Designer HTML/CSS expert QA Engineer Copywriter External Contractor Supportive (S) Helps the team on request only to do work, to spread results into masses.This is the sub-role of Responsible. Anyone with partial hands-on engagement. For example, QA helps Product Manager with research on automation tools. Early Adopters Consulted (C) Shares knowledge and opinions with the team to tune outcomes into what they believe is right without doing any significant work within the team. Subject Matter Experts (such as Legal Advisers) IF NO ONE ELSE (N) The person that wants to move away from the activity but possesses domain knowledge and will help if no one else is available. An Engineer who jumps in to fix critical issues because others are not available. A Product Manager organizing yearly meetups for colleagues. Informed (I) Is actively or passively informed on changes. Project Manager is informed of the hiring progress. Employees are informed of the legal changes. User (u) Does not participate in the task but will use the end result. Employees who benefit from the company's policies. Office residents who use the office facilities. Occasional User (r)︎ Occasionally uses something. Krakow office residents who occasionally use the Kyiv office. Now, here's how authority, responsibility, and accountability tie in with each role: Has authority? Has responsibility? is accountable? Responsible (R) Yes Yes Can be Approver (A) Yes Yes Yes Team (t) Can have Yes No Supportive (S) Can have Yes No Consulted (C) No Can have No IF NO ONE ELSE (N) Yes Yes Can be Informed (I) Yes No No User #4 ︎(u) Yes No No Occasional User (r)︎ Yes No No Both RAtSCIur and Holacracy create systems that distribute authority and empower team members to make decisions for themselves. Thus, product managers aren't shouldered with all the responsibility for the execution of a project. A key takeaway here is that good leadership is also tied to healthy communication. So when it comes to cooperating with developers, designers, marketers, knowledge holders, and internal stakeholders, we've got a few tips: Set up a clear goal. Meetings without a goal are bound to be unproductive. Before any call, ask yourself: what is your main message? Set aside time for small talk, but quickly get to the point – and stick to it. Have a plan. Always come to meetings prepared. Do your homework, gather the materials you will need in advance, and clearly communicate what you need from your colleague. Remember the audience. Speak the language of your audience. You will need to present the information differently depending on who you are meeting with (marketers, designers, finance experts, etc.) For instance, finance experts might want to know the costs. Doze the information. Don't overload your colleague with tons of unnecessary information. It's totally fine to vent (in moderation). But if you're unhappy with something, provide others with the information they need to help you. Respect others' time. Don't waste your coworkers' time by scheduling unnecessary or overlong meetings. Always check whether a face-to-face meeting is really needed; oftentimes, a Slack message will do. At the end of the day, small choices like these can save everyone a lot of time. Decision-Making in SaaS Product Management As we mentioned, SaaS product managers are the primary (but not exclusive) decision-makers within the cross-functional product team. They make day-to-day decisions through a combination of data analysis, research of potential solutions, and knowledge of the product and industry best practices. Sometimes, there is no 'right' decision. For instance, when it comes to choosing a new feature to implement, there might not be an obvious candidate in your roadmap. As a PDM, you must make an educated guess based on your knowledge of what's best for the product. However, major decisions aren't made in a vacuum. Therefore, our product managers leverage decision-making frameworks, such as BRIDGeS (more on that later), to explore the context and brainstorm solutions with other product experts. Similarly, product strategy decisions are typically made in conjunction with 3-10 c-suite executives and other stakeholders (product directors, marketing leads, senior data analysts, etc.) Again, the frequency of these meetings depends on where we are in the product lifecycle. At the growth stage, once a month. At the maturity stage, once or twice a year. How to Make Data-Driven Decisions and Track Product Performance Throughout the product lifecycle, SaaS product managers will use product analytics dashboards to track revenue metrics, catch fluctuations in user behavior, identify bugs or bottlenecks in user flows, and pinpoint areas for improvement. Some examples of dashboards are product funnel, customer service, or cohort analysis report. Put simply; product dashboards allow SaaS PDMs to track product performance and make data-driven decisions on the fly. To make the most of them, product managers should review the dashboards once or twice a week. Our PDMs typically dedicate about one hour per week to this task. Now, product managers are responsible for choosing the metrics that dashboards are built on. Since B2B SaaS products differ in more ways than one (different business domains, feature sets, audiences, subscription models, etc.), it's important for PDMs to create custom dashboards that are tailored to the product. This will ensure that decisions are made using only the most pertinent data. We often use the AARRR framework as a guideline when creating the initial product dashboard for a new product. The acronym stands for Acquisition/Awareness, Activation, Retention, Referral, and Revenue. When paired with relevant metrics, this framework helps our product managers understand how well the product is performing on the market. Among other things, it allows them to pinpoint and investigate holes in the conversion funnel, e.g., why are so few users activating their accounts? How can we change that? In addition to AARRR metrics, here are some of the most common metrics that feature on SaaS product management dashboards. North Star: The metric that is most indicative of product success. It might be any of the below, but it is usually a financial or user engagement metric. Monthly Recurring Revenue (MRR): The predictable total revenue generated by all active subscriptions in a particular month. Annual Recurring Revenue (ARR): The predictable total revenue generated by all active subscriptions over the course of a year. Customer Acquisition Cost (CAC): How much it costs to acquire a new customer. Customer Lifetime Value (LTV): Total revenue generated by a single customer throughout the time that they used your product. NPS (Net Promoter Score): Measures user satisfaction; how much users are willing to promote your product to others. Churn. Defines users who abandoned the product or canceled their subscription. Active Users Per Day (DAU) or Month (MAU). Tells you whether or not users are actively engaging with your product at a sustainable rate. Bear in mind' active user' is defined differently for each product. Stickiness of DAU/MAU Ratio. When daily active users are divided by monthly active users, you can find out whether or not your user base is growing and what this means for your product in the long term. What Is the Balance Between Data-Driven and Vision-Based Product Development? There's no denying that data has an essential part to play in product development. After all, it's practically impossible to track SaaS product performance and achieve a product-market fit without it. But in the race to become data-driven, product managers shouldn't forget about the importance of vision. In fact, they should know that the two are inextricably tied. A product vision is shaped by data, and without a vision, data is useless. The folks at ProductPlan have identified five common pitfalls of data-driven SaaS product management, which we would agree with. The risks are: Exclusive focus on the 'north star' metric, which leads to missed information. Too much focus on data leads to analysis paralysis. Cognitive bias can lead to missed insights or incorrect conclusions. Not collecting enough data can lead to decisions that come too late. Misinterpreted data can lead to misguided conclusions. One of the ways our product managers avoid these pitfalls is by cross-checking the vision with data and vice versa. For example, when we first launched our product, Smart Checklist for Jira, we had big ambitions for its future growth, e.g., adding templates, a progress bar, custom statuses, and much more. Our vision was to become the top checklist add-on in the Atlassian marketplace. But to get there, we knew we had to start small and take a data-driven approach to product evolution. To this day, every new feature or functionality we implement is backed by data, i.e., what we glean from customer support requests, cust dev, user engagement stats, and competitor analyses. But those features/functionalities are also supported and shaped by the product vision. Key Approaches and Frameworks for Saas Product Management The following concepts and frameworks count as some of our organization's key approaches to product development and operations management. Building a Product Roadmap As we discussed earlier, strategic planning is one of a product manager's main responsibilities. Roadmapping goes hand-in-hand with both short- and long-term planning. Product roadmaps help PDMs set achievable goals, conserve limited resources, and share information with the development team and other stakeholders. More than just a list of tasks, the roadmap is a high-level plan that displays the workflow and milestones of a strategy-based pipeline. Some roadmaps are feature-oriented, some are time-boxed, and others are based on quarterly objectives. Here's just one example of a roadmap that is goal-oriented: Prioritize the Feature List and Product Backlog One of the biggest challenges when building a roadmap is deciding what features make the cut. But virtually every highly-successful SaaS business – Github, Slack, Trello – got where they are today by prioritizing new features. Instead of wasting time and money on developing non-essential things, they filled their roadmaps with features that would add genuine value to the product. MoSCoW is one of the most commonly used frameworks for SaaS feature prioritization. So let's break down how it can be applied to the product backlog when building a roadmap. Firstly, MoSCoW is an acronym for Must-have, Should-have, Could-have, and Won't-have. Each of these terms denotes a level of priority from highest to lowest. Must-haves are top-priority requirements. These are features that are essential to product functionality. If we take Uber as an example here, then their 'route mapping' feature counts as a must-have. Should-haves are requirements of secondary priority. These features are considered important but not crucial, e.g., being able to pay via a corporate account in Uber. Could-haves are tweaks that can wait until later in the development timeline for implementation, e.g., a tip jar function in Uber's passenger app. Won't-haves (this time) are features that you still want but can't actually afford under your current budget or deadline. An example might be Uber's ride-scheduling feature, which wouldn't have been essential when the app first launched. Minimum Viable Product In case you haven't heard of this agile product development concept, the minimum viable product (MVP) is a version of your product that contains the fewest features necessary for release to market. A core component of the Lean Startup Model, the MVP allows startups to create a functional product at minimal cost so that they can quickly gather customer feedback and make valuable iterations. We can personally attest to its efficacy because every one of our full-featured products – Mailtrap, Coupler, and Smart above Checklist – began as an MVP. BRIDGeS Framework BRIDGeS is a decision-making and idea-generation framework designed by Railsware. It allows professionals to analyze a problem from various angles, develop targeted solutions, and make a conclusive decision. Sessions can be run either in person (using sticky notes and colored markers) or online with virtual whiteboards (you can try the free Figma template). It takes about 2-8 people to run a productive session. Depending on the issue at hand, attendees may include a product manager and other stakeholders such as software engineers, product designers, marketers, etc. BRIDGeS is an acronym for Benefits, Risks, Issues, Domain Knowledge, Goals, and Solutions. Benefits are what you will gain from a future solution, Issues are your existing problems, Risks are potential issues you might face, Domain Knowledge is information that helps provide context, and Goals are what you hope to get from the future solution. Each type can be added to the board using a different colored card. Here's an example of what the Problem Space looks like after a problem has been broken down using these descriptors. We've used the Uber example again here. In this example, each task has already been prioritized using the MoSCoW method we discussed earlier. So, it is time to move into the Solution Space. This is where we ideate solution variations based on the identified benefits, risks, and issues. We then describe the chosen solution through epics and nested tasks, which can actually be transformed into a product roadmap. Lean Canvas Designed by Ash Maurya, Lean Canvas is a tool for checking the viability of your product idea. It's considered an alternative to the traditional business plan and an adaptation of the Business Model Canvas (the brainchild of Alexander Osterwalder). The purpose of Lean Canvas is to help product managers and startup founders analyze the strengths and weaknesses of their business model and mitigate the risks associated with launching a new product into a competitive and fast-changing market. However, for existing and well-established businesses, the Business Model Canvas is generally the preferred choice. In practical terms, Lean Canvas is a single-page document that consists of nine boxes to be filled in. Their headings are Customer Segments, Problems, Revenue Streams, Solutions, Unique Value Propositions, Channels, Key Metrics, Cost Structure, and Unfair Advantage. Each section allows you to focus on a different aspect of your product offering and structure, to ensure all bases are covered, and the spotlight remains on customer needs. Value Proposition Canvas Created by Strategyzer, Value Proposition Canvas is a tool to help product managers and startup founders get closer to a product-market fit. It can help you understand your customers' needs and pains, find new ways to drive user engagement, and refine your brand messaging and marketing strategy. The canvas is divided into two parts; traditionally, a square on the left (Value Proposition segment) and a circle on the right (Customer segment). Here's a visualization: When filling out the canvas, you begin in the customer segment by listing the customer's jobs, pains, and gains. This part helps you define the tasks customers are expected to execute and any negative or positive experiences they might have while doing them. Then you move on to the left side, where you will deal with the product. Here you will break down products and services, pain relievers, and gain creators related to your product offering. Essentially, these are the benefits (or unique value) that your solution offers to customers. After completing the canvas, you should have a strong idea of how to differentiate your product from others on the market and communicate that unique value to your target audience. Software that Helps Manage SaaS Products Here are some applications and tools that our product managers use to plan new projects, manage their daily workloads, collaborate with teammates, and connect with customers: Figma: For collaborating with designers, wireframing, creating interactive prototypes, and sketching ideas/brainstorming. Slack: For seamless communication with teammates and stakeholders. Google Sheets: For product planning activities and organizing market research/customer data. Looker Studio: For creating free product dashboards and visualizing different aspects of product performance (customer success, ad campaigns, sales leads). Coupler.io: For automating data flows between apps such as Airtable or Pipedrive and destinations like GSheets, Big Query, and Microsoft Excel. Notion or Coda: For knowledge storing, project management, and note taking during collaborations. Typeform: For creating engaging customer surveys. Google Meets and Calendly: For client calls, conducting customer interviews, and meetings with C-suite executives. Now let's dive into something a little different. This next part is for startup founders who are ready to hire a product manager for their team. How to Hire a Good Product Manager Here we'll share our process for hiring product managers who are hands-on, t-shaped, and lead by example. So, in addition to all of the key skills we discussed earlier, there are several others we look for during the candidate screening and selection process. Strong communication skills are a must, of course, since product managers will be working closely with people from all corners of the product and company, as are strong organizational skills since the role involves juggling meetings, research, leadership duties, and so on. Meanwhile, being attentive to details, curious about how the product works, and having a good memory are also highly desirable traits, though not always dealbreakers. Here are a couple of other things we take into consideration: Technical Background In our experience, product managers with technical backgrounds (think computer science or data analysis) are better equipped for the role than those with experience strictly in product design, sales, or marketing. Knowing how to code, how to break down/organize data, and how to spot bottlenecks in development pipelines are highly-coveted skills. Real-World Experience We aren't really interested in management degrees. Instead, we strive to hire PDMs who have experience managing real-world products, preferably in the SaaS space. In addition, they must be able to critically discuss their past experiences and demonstrate a history of problem-solving, decision-making, and true leadership. Resources for Product Managers There are no shortcuts to launching a career in product management or becoming an expert in the field. Unfortunately, no single resource — book, course, podcast — can teach you everything you need to know about the discipline. However, based on recommendations from our product managers, here are some useful materials to help you grasp the essentials. The Lean Startup Already a modern classic, The Lean Startup by Eric Ries is a must-read for product managers working in the SaaS space. It covers the MVP concept in depth and explains how to leverage the ever-popular Lean Startup framework. INSPIRED: How to Create Tech Products Customers Love INSPIRED goes much deeper into some of the topics we've covered here, including the skills product managers need and what processes they should follow. It's suitable for PDMs working at all stages of the product lifecycle, from introduction to maturity and beyond. The Mom Test: How to talk to Customers and Learn if Your Business Is a Good Idea When Everyone Is Lying to You Despite its odd name, The Mom Test is considered one of the top manuals on how to effectively validate your business idea. It explains how to go about the customer development process the right way and extract meaningful insights from your target audience. A note on Mentorship: "If you’re a software engineer, data analyst, or QA and you’re interested in becoming a product manager, the best advice I can give is to find a mentor. Contact a PDM within your current company who is an expert at their craft, set up a meeting, and see if they can help you evaluate the best path forward. This is a great way to find out if the role is really for you." - Yevgen Tsvetukhin (Product Manager) Wrapping Up On a closing note, we asked a couple of our product managers what their favorite and least favorite parts of the job are. Here's what they had to say: "Experimenting is the most exciting part of SaaS product development. By making small changes to the product and properly measuring the results, you can test lots of hypotheses in a real-life environment. On the other hand, the hardest part is having to make unbiased decisions. You don’t always have tons of data to support your position, and you are dealing with stakeholders who, as all humans, have their personal preferences." - Julia Romanenkova (Product Lead) "For me, the most rewarding part of product management is getting to see how your product benefits customers. However, the hardest part is all of the work that comes after the product launch, and before its success. It takes more than an MVP to start seeing that impact." - Julia Ryzhkova (Product Lead) Product managers are strategists. They create data-driven action plans and bring structure to a founder's vision and unity to the contributions of cross-functional teams. In our view, every SaaS company needs designated experts who can answer tough questions and steer a new product along the path to success.

Keeping on top of your project management tasks can be a daunting task, but with the right database and system in place, it’s easier than you think! In this blog article, we’ll take a look at why it’s so important to maintain an effective project management database and how to get started. What Is a Project Management Database? A project management database is a crucial tool for any organization looking to stay organized and on track with their projects. It is an essential part of any project management system and is used to store and access important information related to the project. This information can include task lists, milestones, deadlines, resources, budgets, and more. A project management database ensures that all data related to a project is kept up-to-date and easily accessible. Having this data in one central location makes it easier for everyone involved in the project to access and use the information they need. With a project management database, teams can easily keep track of progress, assign tasks, manage resources, and set deadlines. It also allows teams to monitor budgets and view reports in real time. This helps ensure that projects are completed on time and within budget. Furthermore, with a project management database, organizations can gain insights into how their projects are performing over time so they can make necessary adjustments as needed. In conclusion, a project management database is an invaluable tool for any organization looking to streamline its operations and remain organized. It provides teams with the necessary tools they need to manage projects effectively while also providing them with powerful insights into how their projects are performing over time. Why Is It Important to Maintain a Project Management Database? Maintaining a project management database is essential for the successful completion of any project. It provides an organized system for tracking and managing key components of the project, including tasks, deadlines, resources, costs, risks, and more. By having a single source of data that can be easily accessed and updated by all team members, organizations are able to optimize their workflow and ensure that projects are completed on time and within budget. A project management database also allows for better communication between teams. Instead of relying on emails or other unreliable methods of communication, teams can access up-to-date information through the centralized database. This allows team members to quickly identify any changes or adjustments that need to be made in order to stay on track. Furthermore, a project management database provides valuable insights into the progress of a project. With detailed reports and analytics available at your fingertips, it’s easy to track milestones, pinpoint areas where improvement is needed, and identify potential issues before they become bigger problems down the road. In short, maintaining a project management database is an essential part of staying organized and ensuring that projects are completed on time and within budget. What Is a Work Breakdown Structure in Project Management? A work breakdown structure (WBS) is an essential element of project management. It is used to break down a project into smaller, more manageable tasks. By breaking down a project into a hierarchical structure of discrete activities, the WBS provides an organized view of the project and its components. This allows for better planning and control throughout the lifetime of the project. At its core, the WBS is a visual representation of the tasks and subtasks involved in completing a project. It consists of activities broken down by level, with each level providing more detail about the task at hand. The highest-level activities are usually referred to as “phases,” while lower-level activities are called “tasks” or “subtasks.” The WBS helps to identify any gaps between the tasks required to complete a project and makes it easier to assign resources accordingly. A well-crafted WBS can be used as part of an effective project management database that helps track progress, costs, resources, risks, and more. A good WBS will also help you estimate costs more accurately by breaking tasks down into their individual elements. This allows for better budgeting and cost control during each phase of the project lifecycle. Benefits of Maintaining a Project Management Database A. Improved Organization The organization is the key to success in any project, and maintaining a project management database can help ensure that all aspects of a project stay organized. By centralizing information in one place, it’s easier to keep track of tasks, deadlines, resources, and other important details. This helps teams work together efficiently and ensures that nothing falls through the cracks. With an up-to-date project management database, teams have access to all the necessary information they need to stay on top of their projects and meet goals in a timely manner. Furthermore, this information can be shared with stakeholders outside the team so they can monitor progress without having to ask for updates. A project management database is an invaluable tool for staying organized and on track with projects! B. Increased Visibility and Accountability Having a project management database is essential for any organization that wants to ensure the success of its projects. A project management database allows teams to track progress and hold everyone accountable for their tasks. By having a database in place, teams can easily access data and view performance metrics at a glance. This increased visibility helps organizations stay on top of their projects and make informed decisions quickly. Not only does a project management database provide increased visibility, but it also creates a culture of accountability within an organization. With the data available, team members can easily see what tasks are assigned to them and measure their performance against set goals. This helps create an environment where each team member takes ownership of their role, ensuring that projects are completed on time and within budget. To summarize, maintaining a project management database is essential for any organization striving for success. It provides increased visibility into performance metrics so teams can make informed decisions quickly, as well as creates an environment of accountability where team members take ownership of their role in completing projects. C. Improved Collaboration Having a project management database in place is essential to ensure successful collaboration between teams. A project management database allows all team members to access up-to-date information related to the project, streamlining communication and facilitating better decision-making. This is especially important for large projects that involve multiple teams and stakeholders. The improved collaboration enabled by a project management database also helps to reduce confusion among team members, which can significantly improve the efficiency of the project. By having a single source of truth about the project, each team member can quickly access the relevant details needed to complete their assigned tasks. This eliminates the need for redundant updates or conversations, allowing team members to focus on the tasks at hand. Finally, a project management database also makes it easier for multiple teams to work together effectively by providing an easy way to exchange information and track progress against milestones. This allows stakeholders from different departments or organizations to easily view progress on shared goals, ensuring everyone is on the same page with regard to deadlines and expectations. Types of Project Management Databases A. Spreadsheets Spreadsheets are one of the most popular ways to maintain a project management database. This is because they are easy to set up, contain all the necessary information, and can be quickly modified. Spreadsheets allow you to easily organize data into categories, track progress, and provide an overview of a project’s status. They also offer a range of features such as drag-and-drop sorting, conditional formatting, and pivot tables. Using spreadsheets as your project management database provides many advantages. First, they give you an organized view of your project’s data and enable better decision-making. By categorizing data into distinct columns you can quickly identify key trends or issues in the project and adjust your strategy accordingly. Additionally, the ability to apply various formulas or functions makes it easier to draw insights from complex data sets. Finally, spreadsheets are highly customizable and can be tailored to meet specific requirements or scale with growing needs. This means that regardless of whether your project is small or large, you can always find a way to make it work within spreadsheet parameters. B. Online Project Management Software Project management databases are essential for any organization looking to keep its projects organized and running smoothly. Online project planning software is a great way to manage projects of all sizes, whether it’s a small task or a large-scale project. This type of software helps manage tasks, resources, timelines, budgets, and more. It also allows teams to collaborate with each other in real time from any location. Online project management software provides an intuitive interface that makes it easy for users to create and assign tasks, as well as track progress. This type of software also offers features like task notifications, priority settings, file-sharing capabilities, milestone tracking, timeline views, and more. Additionally, many online project management tools provide analytical features to help teams track their success over time and make informed decisions about future projects. Using online project management software can help streamline the workflow process by enabling efficient collaboration between team members. This allows teams to stay on top of progress and deadlines without having to manually enter information or sift through emails looking for updates from each team member. C. Customized Solutions When it comes to project management, having a reliable database is essential. A customized project management database can make all the difference in the success of your projects. Not only do they provide you with a way to store and access data quickly and easily, but they also allow you to tailor the system to meet your specific needs. Customized solutions offer a variety of advantages over traditional solutions. For starters, they allow you to customize the system in order to suit your exact requirements. This means that you can add or remove features as needed, allowing you to tailor the system so that it best serves your project’s needs. Furthermore, customized solutions often come with additional features that may not be available in traditional solutions, such as workflow automation, advanced reporting capabilities, or integrated analytics tools. Another benefit of using customized solutions for project management databases is the improved security. With these systems in place, you can ensure that sensitive data is kept secure from unauthorized access and tampering. Additionally, customized systems typically offer more robust backup and recovery options than traditional solutions, giving you peace of mind should anything go wrong with your database. How to Create a Project Management Database A. Gather Requirements Having a project management database is an essential tool for any successful project. It allows you to track and monitor the progress of the project, ensure that tasks are completed on time, and keep all project-related information organized. However, in order to create a successful project management database, it is important to begin by gathering requirements. The first step in gathering requirements for a project management database is to identify the purpose of the database. What will it be used for? Who will be using it? Knowing these answers will help you determine what features and capabilities your database needs in order to meet those needs. Once you know the purpose of your database, the next step is to determine what data needs to be stored in the system. This includes not only the type of data that needs to be stored but also its format and structure. For example, if you need to store customer information, then you should determine what fields are needed such as customer name, address, contact information, etc., as well as how this data should be structured within the system. B. Choose the Right Software or Platform When it comes to choosing the right software or platform for your project management database, it’s important to consider your specific needs and the goals of your project. Depending on the scope of the project, you may need to choose a more comprehensive solution than what is available from basic software programs. There are a variety of solutions available for creating and managing a project management database. Some popular options include Microsoft Excel, Access, and SharePoint. Each has its own merits and drawbacks that should be considered when making a selection. Microsoft Excel is one of the most popular platforms for creating a project management database due to its flexibility and ease of use. It can be used to create simple spreadsheets or more complex models depending on the user’s needs. However, it does not have many built-in features specifically designed for managing projects and can be difficult to use with large datasets. C. Document Your Processes Organizing and tracking projects can become a daunting task for any organization. To ensure consistency and accuracy, it is important to document processes and store them in a project management database. A project management database provides a centralized repository for all project data, enabling teams to quickly access the information they need. Having an organized and up-to-date project management database is essential for successful project delivery. It allows teams to easily access relevant documents, track progress, identify roadblocks, and make informed decisions. A well-maintained database also helps streamline communication and collaboration between team members. Creating a project management database involves several steps. First, define the scope of the project by considering who will be using the system and what data needs to be collected throughout the process. Once the scope of the project is determined, create a list of objects that should be stored in the system (e.g., contacts, tasks, milestones). Then, decide on how data should be structured within each object (e.g., fields, tables). Finally, establish rules for data entry (e.g., naming conventions) and make sure that everyone on the team is familiar with them. D. Train Your Team Proper training is essential for any successful project management database. Without the right knowledge and skill set, it can be difficult to effectively maintain and use a project management database. To ensure your team is well-equipped to manage and use the database, it’s important to provide them with training on its features and functionality. The first step in training your team is to provide an overview of the project management system. Make sure they understand the purpose of the system, how it works, and how they can use it to their advantage. You should also explain any specific tools or features that are available such as reporting functions or workflow automation. Once your team has a basic understanding of the system, you can move on to more advanced topics like data entry protocols, query-building techniques, and report design principles. It’s also important to cover any security measures that are in place so that your team knows how to protect sensitive information from unauthorized access. Conclusion In conclusion, maintaining a project management database is essential for any organization that wants to successfully manage its projects. It provides an efficient way to store and access project data and allows teams to collaborate more effectively. Additionally, it allows organizations to track progress, identify issues, and ensure projects remain on schedule. A strong project management database helps ensure that all goals are met in a timely manner while also providing the necessary information needed for accurate reporting.

Delegating power is a crucial aspect of managing teams effectively. It enables managers to assign tasks and responsibilities to team members, allowing them to focus on their areas of expertise while empowering them to take ownership of their work. This method can lead to increased productivity, improved morale, and more efficient use of resources. However, failing to delegate power can lead to micromanagement, burnout, and a lack of trust among team members. This is something I have experienced firsthand in my previous jobs, where managers were hesitant to delegate tasks and responsibilities, negatively impacting the overall management and performance of the team. Focus on Management Expertise One of the primary benefits of delegating power is that managers focus on their areas of expertise. Managers can free up time and energy to focus on more important and pressing matters by assigning tasks and responsibilities to team members. This can lead to increased productivity, as managers can devote their full attention to the tasks that require their expertise. Empower Teams To Own Their Works In addition to increasing productivity, delegating power empowers team members to take ownership of their work. When team members are given the autonomy to handle their tasks and responsibilities, they are more likely to take pride in their work and feel a sense of accomplishment. This can lead to improved morale, as team members are more invested in their work and motivated to perform at their best. Efficient Resource Management Another important aspect of delegating power is that it can lead to more efficient use of resources. Managers can ensure that the team is working at its total capacity by assigning tasks and responsibilities to team members who are best suited to handle them. This approach leads to increased productivity and improved outcomes, as team members can focus on the tasks they are best suited to handle. Avoid Micromanagement However, delegating power can be challenging for some managers. Many managers may feel they are the only ones who can handle specific tasks or need to control everything to ensure that the team is working effectively. However, this mindset can lead to micromanagement, negatively impacting creativity and innovation. Another consequence would be a lack of trust and respect between the manager and team members. The Art of Sharing Power To effectively delegate power, managers must understand that delegation is not about giving up control but sharing it. Managers should be clear about their expectations and provide team members with the necessary resources and support to be successful. They should also be willing to trust team members and give them the autonomy to make decisions and handle their tasks. In conclusion, delegating power is an essential aspect of managing teams effectively. It allows managers to focus on their areas of expertise, empowers team members to take ownership of their work, and leads to more efficient use of resources. By understanding that delegation is about sharing control and being willing to trust team members, managers can effectively delegate power and lead their teams to success.

Today, I would like to share a management practice we developed at New Relic. It was one of the best things we did as an engineering organization. The practice is called “Mini-Ms." I believe it’s as important a practice for managers as code reviews are for engineers. This post is the first of a series: In this post, we look at how Mini-Ms work and what they are. Next, we learn how to implement Mini-Ms. Then, we discuss variations you may want to consider. Finally, we share a history of Mini-Ms, including where the name came from. What Is a Mini-M? A Mini-M is a group of managers that meet weekly or biweekly. The meeting is a combination support group and a working session. In each session, managers share the challenges they face. The other participants offer support and help problem-solve. Why Are Mini-Ms Effective? What is the value of meeting with other managers and talking about your problems? It may not seem like it is worth the time. Yet, many managers claimed Mini-Ms helped them grow more than anything else. Mini-Ms Help You Develop Skills There are a few reasons for that. Elaine May describes three reasons: “Learning to manage is very different from other types of learning (like engineering, for instance). In management, the concepts are simple and the execution is not. I’ve seen this trip up many engineering managers who read a book or attend a class and find the concepts trivial and therefore easy or not very important. Learning management is more of an apprenticeship versus an intellectual pursuit.” “In a Mini-M, you have many other people to learn from. If you are only learning from a coach, manager, or mentor, their approach may not fit very well for you, but in a Mini-M, you are getting multiple perspectives.” Teaching clarifies your thinking. When you share your experiences and ideas with other managers, you’re forced to articulate your own practice and consider it in a critical way. I have a few more explanations: Skills are unevenly distributed. You might be good at running meetings. I might be good at 1-1s. Another participant might be an effective project manager. During a Mini-M, we all share our experiences with each other. Imagine having to fill in those skills some other way. You would have to study each of those topics or learn each of them the hard way. That would be much slower! The diversity of the group allows the group to grow faster. Mini-Ms meet you where your skills are. Most alternative methods of learning involve assumptions of where your current skills are. For example, a management course tries to teach you a certain set of concepts or practices. But Mini-Ms allow you to expand your skills from wherever they may be. If I am struggling with how to run a particular meeting, I can immediately add a little to my skills during a single Mini-M session. This makes the M-team into a combination of a support group and training session for your management team. Mini-Ms Are a Source of Valuable Support Management is a difficult profession. As hierarchical creatures, being “higher” in the hierarchy separates you from your team members. And other managers are often busy and unavailable. Because Mini-Ms were largely modeled on support groups, your group can become part of your support network. Even outside of the meetings, you might turn to your fellow managers for help. Having a Mini-M helped me to build up a mental map of the skills of the managers around me. This was helpful because I started to understand the skills that I needed to build. When I ran into problems running projects, I felt like I could go to the person I knew was good at it and ask for help. And because we had a relationship from our Mini-M, they were more likely to want to help. In addition, many companies are distributed nowadays. This can result in less accidental interaction with peers, and it can contribute to isolation. Mini-Ms can be a source of connection with other managers. Mini-Ms Help Retain and Attract Managers Because managers feel better supported by their peers, they are more likely to stay at the company or stay in management. I anticipated that benefit. What surprised me was that people outside the company seemed to keep hearing about these Mini-M groups. And they would bring it up during interviews and mention it was why they applied in the first place! Why were they so attracted by Mini-Ms? They demonstrated that we took management seriously as a role. They showed that we valued developing our people, which was a signal that their job as a manager would be better here. They showed we experimented with our organizational practices and would welcome further innovation. Mini-Ms Help Build a Management Culture Along with a support group, the other inspiration for Mini-Ms was a conspiracy. The idea was to bring a few managers together, gripe about the problems in the organization, and come up with solutions. Mini-Ms naturally became the graph along which many management practices spread through the organization. In the Five Dysfunctions of a Team, Lencioni talks about the importance of managers seeing their “first team” as the management team. Mini-Ms helped develop a community of managers who all were focused on improving their skills and their teams. Many of us felt empowered to address the problems we saw in the organization around us. How Does a Mini-M Work? There have been a lot of variations to the way Mini-Ms have run over the years. What follows is a good way to start Mini-Ms. The Organizer of the Mini-Ms assigns each manager to a Mini-M. Each Mini-M has five to eight managers. The Organizer sets the expectation that managers attend. Each group has a Facilitator. They schedule and facilitate meetings. They usually start with a standard meeting format. Here’s an example format: Each person brings a topic: something that was challenging from last week, or something they are facing now. In an in-person meeting, the Facilitator would go around and ask everyone for their topics and put them on a whiteboard. In a distributed setting, all the participants would add their topics at the same time to a shared doc. Everyone gets three votes. They put them on the topics they would like to discuss. The group goes through the topics and discusses them in turn, ordered by the topics that have the most votes. The Facilitator checks in every five minutes to see if the group is finished with the current topic, or wants to continue the discussion. This is based on the Lean Coffee meeting format. The Facilitator sets the expectation that meetings are safe places. Participants discuss sensitive topics and there is an expectation of confidentiality. For example, a manager might talk about the challenges they were having with their manager. When To Use Mini-Ms You should design your Mini-Ms based on the particulars of your company. The size and company culture are particularly important. One precondition to this being successful is that the environment is a supportive one. If the leaders value learning and growth, they are more likely to support Mini-Ms properly. A competitive culture may not be a good fit. I recommend Mini-Ms to companies with product-market fit. Early in the growth of a company, product-market fit is the most important factor in a company’s success. After you’ve found a good fit with the market, organizational effectiveness moves up in importance to become one of the most critical factors for your success. At that point, M-Teams begin to contribute more directly to the success of the company. While you can lay the groundwork for M-Teams earlier, I wouldn’t recommend them in most early-stage companies. You can use Mini-Ms globally, across an organization, or within a smaller group. You can even implement a Mini-M informally, with a smaller group of managers. If you start informally, be sure to read the History section to see how they evolved at New Relic. How Do I Implement Mini-Ms? We get to that in our next post. Thank You Not a lot has been written about Mini-Ms, but there is one post currently on the New Relic blog, and another that has mysteriously vanished. Darin Swanson authored some content that was inspirational for large parts of this article. He and I have worked together on helping other companies implement Mini-Ms, so contact me if you’re interested in help. He also provided feedback and suggestions on drafts of this article. He encouraged me to explain the first team concept more fully, and to describe why pre-product market fit companies may not be a good match. And he suggested I split the content into separate articles. Nic Benders was one of the co-founders of Mini-Ms. He reviewed this post, offered feedback, contributed to the history section, and described some of the design goals for Mini-Ms. Elaine May provided feedback, some of which was so good I just ended up quoting her. She was gracious enough to offer some talk to talk about her experiences setting up or participating in similar programs at other companies, and she talked about her experiences with me in New Relic’s Mini-Ms. Elaine introduced me to the Chatham House Rules, which I incorporated into the post. Bjorn Freeman-Benson was the grandfather of the Mini-M. He shared a lot of his thinking about the principles behind why Mini-Ms were successful and what they were aiming for. He advised me to break up this post into sections and make it easier to get to the implementation section. And shared overall feedback. Merlyn Albery-Speyer helped me improve the section on “when to use Mini-Ms” by pointing out some preconditions for success. He pointed out that the structure became less important after the Mini-M is established. Merlyn pointed out that we tried to keep people from being in the same Mini-M as their managers, or other people reporting to the same manager. He also shared the theory about VPs not being willing to be vulnerable as a possible explanation for why the Mini-Ms never took off in manager-of-manager groups to the same extent they did for frontline managers. Jason Poole shared his experience as an Organizer of Mini-Ms. He pointed out a now mostly disappeared second post on Mini-Ms. He also suggested ways Facilitators could counter unproductive ranting. Marty Matheny shared feedback based on his experience as an Organizer. He helped improve the advice for Organizers. And he pointed out that engineering adjacent departments participated. Chris Hansen pointed out that confidentiality was an issue with whiteboards. He noticed an error that would have been embarrassing. He pointed out the value of M-teams in distributed organizations to counter isolation among managers. He also added some advice for participants. Chris also helped with a point about the value of the first few meetings. Teresa Martyny reviewed a draft of this post and pointed out some redundant assertions I was making. And she recommended I break this into multiple posts or edit for brevity. Natasha Litt was another early Mini-M leader, and she reviewed a draft of the post and contributed to it.

It's no secret that a tech startup is only as good as its engineering team. It's tempting to follow that statement by saying an engineering team is only as good as its talent. That's true, to some extent, but it takes expertise and leadership to get the most out of your talent—and, of course, to identify and recruit the right employees in the first place. To use the most obvious analogy, even an all-star soccer team is unlikely to win a championship without a savvy coach at the helm. Similarly, even the most stacked engineering team (pardon the pun) risks falling short without a smart and persistent leader. As the engineering lead at a growing up startup, I've experienced success and navigated numerous challenges. While a leader's role is multifaceted, steering the ship through difficult times is one of the most critical aspects. So let's take a look at the three biggest challenges I've encountered and how they can be overcome. 1. Hiring the Right Mix of Skills To continue the soccer analogy, imagine for a minute that your team comprises some of the country's highest-ranked players. The only catch: they're all defenders with no forwards or midfielders. Good luck winning any games without the right mix of skills. In the context of an engineering team, the same principle applies. Everyone needs the same core skills, but different team members should possess different complementary skills. For example, it's not useful to have a team of people who are all experts in CSS but no one who can tackle the API. Similarly, if everyone is outgoing and eager to develop, but no one is thinking granularly about tech debt or reviews, your team will be hindered by the imbalance. A highly tailored hiring process is the key to ensuring your team is well-rounded. To start, map out what skills your team already possesses, what skills it needs, and what skills you expect it to need in the year or two ahead. Then, tailor the hiring process to that. A coding challenge is one of the best ways to get to know how a prospective employee thinks, particularly since you can adjust the rubric to emphasize the skills your team currently lacks. It's basically akin to a try-out. In addition to looking for engineers that complement existing employees, you should also look for ones with the potential for upward mobility. I love bringing in eager-to-learn junior engineers and offering them the support needed to grow. When senior developers mentor new employees, it improves team cohesiveness as well. 2. Toggling Between Creative Endeavors and the Project Roadmap A key component of leadership is balance—not just balancing your team's skill mix but balancing their focus. You must encourage team members to split their time between adhering to the project roadmap and pursuing innovation. Product innovation is crucial for our team because many of our engineers fit the user profile. They have the best pulse on what's working and what could be improved. In addition to outlining a clear product roadmap, encourage engineers to keep an eye out for potential enhancements—particularly those that would be considered low-hanging fruit. Employees should give about 50% to 60% of their time to building things on the roadmap and the rest to things they want to work on. For the latter, I don't mean irresponsible passion projects. Innovation should still relate to overarching company goals, whether activating users or speeding up the release process. Smaller side projects should always align with the team and the company. As the engineering lead, it's your job to ensure your team reviews company goals, discusses innovation, and follows the roadmap. Ideally, your team should be in conversation with other teams in the company, too, to ensure alignment. 3. Keep Morale High Despite Headwinds and Uncertainty Last, it's important to understand that your team doesn't operate in a bubble. The news cycle is full of concerning headlines about slow economic growth and a looming recession. A good leader will acknowledge this reality and explain to employees what it means for the company at large and the engineering team in particular. For example, perhaps there will be fewer new hires as a result of overall company finances. Explain this to your team and how it affects where the team should focus its efforts. Sometimes, hiring fewer people actually makes for an exciting challenge, as there's far more room for creative solutions and cross-team experimentation. Regardless, it's crucial to explain the macro situation to your team clearly and give them the opportunity to ask any questions. If there's seemingly bad company news at an all-hands, for instance, set up a time to debrief and discuss new information as a team afterward, in addition to addressing concerns during one-on-ones. The tech industry might be facing more headwinds than usual, but it's still an exciting industry with tremendous room for growth. As a leader, it's your job to remind employees of this reality and help them embrace challenges. It's still a fantastic time to be in tech and an exciting time to serve as engineering lead. If you can overcome these three top challenges, your team will be well on the way to success.

Most of us that work in cyber security are well aware that there are not enough people to fill all of the positions that we have opened. There is a severe shortage of trained and experienced people who are capable of securing the systems that we are entrusted to protect. Application security engineers, DevSecOps professionals, security architects, you name it, there's a shortage. We will never have the staff, budget or time to do all the security work we want to do. One of the ways that we can address this is by scaling our security teams and programs. When I say scaling, I don't mean what you do to a fish after you catch it. I mean finding a way to do more with less. This can involve automation, creating self-service systems, and many other potential solutions. In this series of blogs, we will discuss how you can solve this problem by building a security champions program for your organization. What Is a Security Champion? A Security Champion is a team member that takes on the responsibility of acting as the primary advocate for security within the team and acting as the first line of defense for security issues within the team. Or, more plainly: The person who is most excited about security on a team. They want to read the book, fix the bug, or ask security questions. Every time. Security champions are your communicators. They deliver security messages to each dev team, teaching, sharing, and helping. They are your point of contact, delivering messages to and from the security team and keeping you up to date on what matters to your team. They are your advocate. They perform security work, for their dev team, with your help. They also advocate for security, asking questions in situations you would have been left out of. Raising concerns you might have missed. They are a peer for everyone on their team and can influence in ways that you yourself cannot. In the next few paragraphs, we will cover how to build an amazing security champions program! We will follow this recipe: Recruit Engage Teach Recognize Reward (Over)Communication Metrics and Data Conclusion (Don't Stop!) How Does One 'Attract' Champions? The #1 most important rule of recruiting security champions is that you must attract them. Do not "volun-tell" someone to be a security champion. That person is not going to do their best for you, and they or certainly won't enjoy the experience. Attract the right people instead of forcing them. Performing Outreach Use lunch and learns to teach about security. Arrange security training. Anyone who asks questions or attends all the events is a potential champion. Use interesting titles for events if you can. Add a note to your email signature saying you are looking for champions. Put a sign on the fridge in the kitchen. Talk about it at the all-staff meeting. Send an email to all of IT. Security Champions at Work! Use lunch and learns to teach about security. Arrange security training. Anyone who asks questions or attends all the events is a potential champion. Use interesting titles for events if you can. Add a note to your email signature saying you are looking for champions. Put a sign on the fridge in the kitchen. Talk about it at the all-staff meeting. Send an email to all of IT. Observe Pay attention to who responds, attends events, asks questions, and who is 'always there.' Those are the people you need. Adjust Your Attitude Change your team's mantra to "I am here to serve you," and your team will attract even more candidates. Saying "you are my customers" to the rest of IT if you are a security professional, is basically the truth. Plus, you always get more bees with honey. #2 most important rule of recruiting: ensure their manager is on board. You don’t want this person to have to fight to do work for you or feel conflicted. Ensuring their manager is comfortable. Engaging Your Champions If we want IT professionals to join our security champions programs, we must make participating interesting and appealing. We want to motivate them; to do extra work on top of their regular job, to care about security, to learn a lot of new things, and to work with us. So it needs to be good. Engage: To occupy, attract, involve – in security activities! To participate or become involved – with your champs! A Few Ideas For Making Your Champions Feel Engaged If possible, bring them on a security incident related to software. Teach them what it's like to respond, the consequences, and just how much damage insecure code can cause. Share (appropriate) secrets with your champions. If you are going to share quite sensitive info, inform them of the concept of 'need to know, then 'Deputize' them onto your team for that one meeting. Being vulnerable and admitting mistakes is a great way to get buy-in and interest. Let your champions see everything first. New tools, documents, policies, changes, etc. And ask their opinions. First, they will likely have great ideas, and second, it makes them feel like they matter. Create a mailing list for your champions to tell them about new security stuff. Send them links to podcasts, articles, events, or anything else that you think is relevant and that they may find interesting. Meet with them 1:1 once every month, and have a pre-set list of questions. Potential questions (thanks to my friend Ray at Hella Secure Blog): What are you working on? What are you going to be working on next? Do you need any help? These questions will spark conversation and lead you down the right path. That said, when you ask questions like this, brace yourself for potentially bad news so that you can play it cool if they reveal something that makes you cringe. Hold team-building events, and let them know each other. Having a friend on a team always makes it worth coming back. Invite them to join security communities, such as OWASP, or We Hack Purple Community (of which they are free to be part of!). There are many ways you can make the champions feel engaged, and one of the best ones is to give them training, which is what we will talk about next. Teaching Security Champions You are in a room full of brand-new security champions, and they are itching to learn all about 'cyber'; what do you do? What do you teach them? How do you impress them? Only teach them what they need to know. Nothing more. As someone who creates security training professionally, I have to say I've seen a LOT of filler. Extra content that just does not need to be there. Software developers do not need to know the history of Diffie-Hellman or the difference between symmetric and asymmetric encryption unless they are building encryption software. So don't try to teach it to them unless they have a keen interest and have asked about it. What they really DO need to know is: What you need, expect and want from them, as champions. You should define the goals of your program and share them with your champions. Share your plans for them as much as you can. Give them timelines, training information, or anything else you have. You need to clarify what you expect, or you may not get it. Technical Topics For Teaching Your Security Champions: Formal training on secure coding with labs! Threat modeling Secure architecture (whiteboarding) Code Review How to fix the bugs they find. Repeat yearly as a minimum. Topics Specific to Your Organization: Which policies, standards, and guidelines apply to them? Help them create missing guidelines. Teach them how to be compliant, and help them get there. Their role during an incident. Job shadowing Hold consultations to let them provide input on the policies affecting them. Trust me; their feedback will be priceless and make them feel heard. The last topic you need to ensure they learn is tooling. If you expect them to use a tool, you need to show them how, what the output means, how to validate the results, and how to install and configure it. It is also your job to either help them pick excellent tools or involve them when you are choosing tools for them. Recognizing and Rewarding Security Champions Suppose you've ever read the book The 5 Love Languages or articles summarizing the five love languages. In that case, you are aware that there are predictable patterns in how people respond to various acts of kindness. Someone's "love language" is the specific type of kindness that they are most affected by. For example, someone whose love language is "words of affirmation" would respond very well to receiving a glowing performance review, a compliment on a new article of clothing, or accolades from their colleagues about a project they worked on. You may be wondering at this point if you accidentally clicked on an article from a women's fashion magazine, not a technical article from Tanya Janca, AppSec Nerd Extraordinaire. Please have a bit of faith, and read on. The Five Love Languages Are: Gifts Words of Affirmation Physical Affection Spending Quality Time Acts of Service When we are creating a security champions program, it's very important that we ensure the champions feel appreciated. We don't want them to feel squished into doing two jobs for only one paycheck. One of the biggest challenges that security teams face when creating a champions program is having it fall apart after the first few months, either due to the security team losing steam or champions losing interest. We need them to feel very aware of our gratitude and interest in the program itself for them to continue to want to serve the security team's agenda. As you likely already figured out, not all the love languages listed above are work appropriate. We can't run around giving hugs or holding hands with other employees. That said, we can adapt most of them for work situations so that we can show the champions they matter to us in appropriate ways that support our security program. Below is a non-exhaustive list of several ideas to make your champions feel as valuable as you know they are for your program. 1. (Security Related) Gifts Physical or digital security-related gifts; books, videos, training, and CTFs. Create a Certificate to put on their wall. Stickers, posters, or any other decoration that is security-focused. Tickets to a conference or training. 2. Words of Affirmation Make sure to put a note in their performance review about them being a champion. Tell their boss every time they do something that makes a big difference. Send them an email and tell them when they did something big, let them know that YOU saw. Recognize them in front of their peers (special virtual background, a star on their name is slack, etc.) Digital badges for signature blocks. 3. Physical Affection High Fives are the only recommended form of physical affection that you should show another employee. High fives signal success and your approval of whatever they just did. (And only give high fives if you are confident that the employee is comfortable. If they seem hesitant, don't do it. Please also be mindful that some religions and cultures do not allow those of the opposite sex to touch each other; please be respectful if this applies. Never push physical touching at work.) 4. Spending Quality Time Giving them your time is a reward. When you do, give them your undivided attention (put your phone away), and turn your body towards them. Let them see a new tool first, and give them a "sneak preview" ahead of everyone else. Let them help you make decisions. Ask for advice from them and feedback, then take it seriously. Invite them to attend security events with you. Whenever you meet with them, this is quality time. Ask them: What are you working on? What are you going to work on next? Do you need any help? 5. Acts of Service Help them with more than just security. Are you good at design? Help them with it! Are you great at presentations? Offer to let them practice in front of you. You don't need to do this very often; just once can make a huge impression. Make introductions where appropriate. "Oh yeah, Chris from QA uses that tool; I'll introduce you so you can learn." Find answers they need to security questions and problems. Never leave them hanging. When people feel appreciated and valued at work, they work harder (many studies show this to be true). Your champions already have full-time jobs on other teams; they are going above and beyond for you. Let them know that you are very aware of them by always making them aware of it with your actions, not just your words. (Over)Communication With Your Security Champions To start off with, pace yourself. Often when I speak to security teams who have a failed program, they tell me how they started off very strong. "We gave them two different pieces of training, two workshops, and three lunch and learned, all in the first three months. Then we were exhausted. We haven't done anything with them in over a year." Unfortunately, this scenario is far too common. To pace yourself, I suggest meeting each champion monthly for 30 minutes. Then hold one lunch and learn and send one email to the champions. This might not sound like much, but you must remember they are already doing a full-time job for your organization. In my 1:1 meetings, I like to ask the following questions (adapted from Ray Leblanc's Security Champions article on Hella Secure blog): What are you working on? What are you going to work on next? Do you need any help? Each of these questions is open-ended, with the hope that it will prompt a meaningful conversation. I usually take notes during the meeting and then send them to both of us, with any action items for either of us highlighted in bold. (Note: I've used this technique to get many of my previous bosses to do things for me. Set a reminder for a week from then, and then reply-all to that email chain and ask: "Any updates on these action items?" It works like a charm!) In your lunch and learn (which does not need to be at lunchtime or involve food), teach them something you want them to know. Do not teach them things they do not need to know unless they asked for that topic specifically. During this session, you or a teammate can teach, or you can show them a training video you like or even a recording of a conference talk that really hit home for you. If you show them something pre-recorded, ensure you watched it first, you don't want to waste anyone's time with death-by-powerpoint. The more fun you can make these sessions, the better. If you're up for it, invite all of the developers and let everyone learn something new! Ideas For Lunch and Learn Topics The specifics on how to apply policies, standards, and guidelines. This could be a secure coding workshop or a threat modeling session. Talks about the top vulnerabilities that you are seeing in your own products, including the risks they pose to your specific business model. Workshops on how to use the tools that your team wants them to be responsible for. Especially how to configure them, how to validate results, and where to find information on how to fix what they find. If they are responsible for design or architecture, give them secure design training. Tell them about a security incident your team had and how it could have been prevented (assuming you are allowed to share this information). Hold a consultation on the new policy, standard, or guideline your team is considering publishing. Ask for their feedback, then adjust your documents accordingly. Remember to take attendance (for metrics) and take notes of any questions for you to follow up on. The Monthly Email Sometimes you just don't have time to do a lunch and learn event or hold 1:1s, but you still need to send a monthly email. The monthly email lets the security champions know what's going on and that they still matter to you. The program is still running because you sent an email. If you don't send this email and you haven't touched base in any other way, this leaves a space where your program may start to disappear. The monthly email does not need to be fancy and doesn't need to say a lot. Generally, the monthly email says: What events are happening this month at your org (lunch and learn, all staff, any other meeting they should know about) Any updates your team has (new policy, the new tool, project updates, etc.) Anything interesting from the news that they may find valuable Any local security events they may be interested in Any podcasts, videos, blog posts, or any other media that is relevant, and you feel relates to them, about security (of course) I live in Canada, and in Canada, we are a country of immigrants. This means we have many, many different religions represented in most workplaces. In December, there's Hannukah, Ramadan, Christmas, and more, and often people take time off for these special holidays. This means having a large meeting in December is darn near impossible. This is the type of situation where you just send the monthly email! It could say something like the following: Hello Security Champions! As it is December and many of you will be off celebrating various holidays, we are not going to have any events this month. We also want to wish you happy holidays, and we hope you enjoy all the snow we got this past weekend! In January we are going to boot the Champions program back up with a lunch and learn on XSS. As some of you are aware, we’ve found it in about 1/3 of our custom apps, and we want to stomp it out in the new year (with your help of course!) An invitation will arrive later this week. In the meantime, please check out this XSS Deep Dive by Tanya Janca. We’re going to cover this topic a bit differently than she does, but it gives you a good idea of what we are up against. Have a great December folks! Sincerely, The Security Team My hope for this section of the article is that you remember to continue communicating with your champions. Don't let your program slip; it will disappear faster than you think. When in doubt, send them an email and check-in. Metrics and Data Following my conference talks, you likely saw my Security Metrics That Matter presentation and understand that I love data. You may wonder why metrics are important. The answer is twofold. We can use data and metrics to report to our bosses and show them we are succeeding. It's evidence of what we are doing and how well it works. You can then use that data again to ask for more resources (staff, tools, budget), a raise, or other changes. The second reason is so that we, ourselves, can improve. We want to improve our program, ourselves, and our results. We can see which activities or methods produce better results when we measure our activities and their impacts. We can then use that information to change our approach for the better. It is important, however, that we do not become fooled by vanity metrics. Vanity metrics are numbers that make us look good but don't necessarily mean anything. My talk on this subject has several stories, but let's tell one. I used to work somewhere, and we all wrote blog posts. We were measured on how many “clicks” we got. A colleague of mine got 10X the number of clicks that I did, and I asked him how he did it. He explained he got the most clicks on Reddit. I was unfamiliar with the platform but thought I would give it a try. First though, I asked for extra data: I wanted to know how long people were staying on our articles. It turned out that people were staying on my articles approximately 1.5 minutes (which means they were reading the whole thing), and on his they were staying an average of 1.5 seconds (which means almost no one was reading the article, they were just clicking the link. This is commonly known as a “bounce”.) The purpose of our jobs was to write articles to help customers know how to use our products, and this means a bounce wasn’t valuable. Armed with this new information, we started comparing different platforms, and it turned out almost all traffic from Reddit were ‘bounces’. I also noticed that my Twitter followers were significantly more likely to read the article when compared to LinkedIn, and LinkedIn got better results than Reddit. My colleague started focussing on sharing links on Twitter (he had more followers than I did), and I started trying to get more followers on the same platform. It turns out that measuring clicks was a vanity metric. The rest, as they say, is history. Now for your security champion program metrics! Measure the following things to see what's working and what's not. Don't forget to report upwards about the ROI (return on investment) your champions program has produced! How many new security champions have you attracted? Measuring program engagement: how many people attended an event, how many people reported issues to you, how many people asked questions. Use the bug tracker for metrics on how many security bugs are being reported and fixed, especially if you have targeted a specific bug class. Also, count how many new instances of that type of bug appear; hopefully, this number will be very low. Instances where champions have told you about a security issue you would not have known about otherwise. If the champions report better work satisfaction and/or fewer missed days of work. Gather stories of your champs saving the day, providing help to their teammates, or anything else that makes for a good story-telling session for upper management. Conclusion: Security Champions Here Are a Few More Tips to Conclude This Long Article: First, start by defining the focus of your program and what is expected from champions. Be realistic; you can only expect one to four hours of maximum effort from them per week. If someone takes a security course but is not on the security team, they may make a good champion. Reach out and introduce yourself. If the mantra of the security team is "it's my job to help you do your job securely," "you're my customer," or "I'm here to serve you," that is very attractive; however, if your team is known as 'the ministry of NO!', you will have difficulty attracting volunteers until you turn over a new leaf. Record every group session and save them. Then, create an onboarding set of champion videos from these recordings so that you can auto-onboard new champions. Some of the videos can also be used to onboard new software developers or other IT staff. Save all the videos so anyone who missed them can see them later. Then, offer up the list of videos to everyone at your organization, if appropriate. Include a TTT (train the trainer) package so your security champions can train their teams as needed. For instance, if you want your champions to give training or talk to their teams, have them follow your package. The package should contain 1) your slides, 2) demo information and instructions to set it up, 3) a video of you giving the talk/training, and 4) a video of you explaining what you are trying to get across for each slide and the entire demo, speaking as though you are teaching someone to give the talk on your behalf. For an example of this, see mine! PS... Feel free to give these talks yourself at your workplace. Lastly, don't stop. Don't give up. Perseverance is the thing that will make this program work. As your program continues, it will grow, and the value that you receive from it will also grow, scaling upwards over time. You and your organization can do this; all it takes is dedication and time. Please feel free to with questions, or even better, tell me about your success with your security champions program!

Incident severity levels and priority are invaluable to solving infrastructural problems faster. This blog helps you understand levels of severity and how they can enhance your incident response process. Major outages are bound to occur in even the most well-maintained infrastructure and systems. Being able to quickly classify the severity level also allows your on-call team to respond more effectively. Imagine a scenario where your on-call team is getting critical alerts every 15 minutes; user complaints are piling up on social media. Since your platform is inoperative, revenue losses are mounting every minute. So how do you go about getting your application back on track? This is where understanding incident severity and priority can be invaluable. This blog looks at severity levels and how they can improve your incident response process. Severity and Priority: How Are They Different? In most cases, the impact on the end user is a measure of the severity of an incident. Information about the error that is coming directly from the monitoring tool helps in classifying the severity level. Every organization will have defined levels of severity and procedures that work well for them. To get started with defining severity levels of incidents, we must first understand how to categorize them. You should ask two major questions: Are major workflows now affected? Does it interfere with a user's ability to complete an essential task? Identifying the most crucial workflows of your apps or services is one of the first steps in defining severity levels. It aids in the identification of what defines an occurrence. Using "SEV" criteria, we may classify incidents according to their severity. Major incidents are classified with lower SEV ratings and require rapid response. Every company must understand its own business, team, and the kind of SEV-level descriptions that operate best for them. As we move further, we have a table that you may use to define severity levels for your organization. It may appear as if incident severity and priority are one and the same. However, isn't it reasonable to prioritize dealing with a catastrophic event over a minor one? In reality, it's more complicated than that for most businesses. Once information about the error has been received, the incident commander will assign a level of priority to the incident. For example, it could be P1 (priority level 1) for issues that need to be fixed at the earliest. Severity talks about the impact on the user, and priority is the order in which the on-call engineers will work on the issues affecting the infrastructure. For example, on an e-commerce platform, if the customers are not able to check out their shopping cart, this is an example of a severe issue. In this specific case, it is a high-priority incident as well. On the other hand, if there is a typo in the brand logo or the font size is too large, it is a high-priority incident without being a high-severity incident. Nevertheless, customers can still continue to shop on the website. Let us consider another example; there is an event that causes your app to crash because it prevents users from doing what they need to do. Therefore, it has a high severity rating. However, that incident affects only .01 percent of your users. However, it may not be considered a higher priority if other incidents are affecting a greater number of users. It's important to know when the two measurements are aligned. However, there are also situations when they might not be aligned. For example, when something is given a high priority, it doesn't necessarily follow that it is of high severity. Defining Severity Levels for Your Organization Not all situations are the same, and not all companies manage them in the same manner. Therefore, in addition to the consequences of an event, you'll need to consider the following when establishing severity levels and the procedures and expectations that go with them. A reliability platform like Squadcast and an e-commerce platform will have different ways of defining severity. As each of these has users with different requirements and tolerance levels, it is critical to first understand what the user expectations are. How to Determine Severity Levels? One must take into consideration the following before deciding on severity levels: High and Low Traffic Periods for Your Service At certain times of the week, your customer traffic may be low. If an incident occurs at that time, a few of your users will be affected. For example, if the shopping cart of an e-commerce site is not functional for certain hours of the day when the traffic is comparatively low, not many users will be affected. The Architecture of Your Infrastructure You may be using a microservice-based architecture that has multiple redundancies and can easily scale up with a higher user load. In such a scenario, the failure of one component will not be considered a high-severity incident as it can be easily replaced with a redundant service. But, for example, if the authentication service goes out, which sometimes cannot be easily replicated, it automatically becomes a high-severity incident since even if the other components are working fine, your users won't be able to use the product. Using SLOs to Determine Severity Levels Since each service has its own specific service-level objective, which determines its functionality, we can use it to determine the severity level. For example, if a particular service's SLO is transaction rate, if the number of successful transactions goes below a certain threshold, we can classify it as a high-severity incident. Levels of Severity Severity definitions are organization-specific. An incident that is classified as SEV-1 may have a lower severity rating in another organization. There are also instances where certain organizations have just three levels of severity. The general rule that is followed is that the more user journeys/workflows that are affected by the incident, the higher will be the severity level. Some organizations may also categorize severity levels on the basis of SLIs (service-level indicators) or SLOs (service-level objectives ) being affected. The table below lists one of many possible ways to define severity levels. SEV-1 Usually, incidents are considered to be SEV-1 if large-scale failures in your infrastructure are occurring that negatively affect most users. For example, critical services are disrupted or unavailable. In addition, database read/write errors, security breaches, and other issues might fall under this umbrella term.If third-party services (such as Google SSO) are down, users may be unable to sign in, which is often considered a level 1 severity issue. SEV-2 Usually, a SEV-2 incident is declared when user experience is severely affected. This can include unacceptably high levels of latency or a significant breach of SLAs/SLOs. These kinds of incidents have the potential to cause major revenue loss for your organization. Any incident that affects more than 70 percent of the users can be classified as SEV-2. SEV-3 An occurrence that has just a minimal impact on the infrastructure but nonetheless creates high load or latency issues for your users. This can include unacceptable long website load times, timeouts for shopping carts, and other similar issues. SEV-4 This is an issue that affects customer experience but doesn't have a major impact on the service's operation. This can include inconsistent load times of pages, display problems in different browsers, and similar issues. SEV-5 Low-level mistakes, such as formatting or display issues that do not impair usability, are classified as SEV 5. This can include typos in product descriptions, incorrect colors being displayed in brand logos, and other issues of that nature. Conclusion It is essential to properly classify incident severity levels to get a head start on solving infrastructure issues. Working with previously defined severity levels helps on-call teams quickly triage major issues. As we have seen in this blog, each organization will have its own specific way of deciding upon the severity and priority of incidents. As the nature and scale of your infrastructure grow and the needs of your user base evolve over time, you may want to revisit and modify the definitions of severity levels. Continuous learning is an essential part of good incident response. We hope this blog is helpful for you in setting the path for better incident response in your organization.

It's no secret this has been a difficult year for many companies in tech. The truth is, it's easy to be a leader when times are good. It's less easy in the midst of a storm. That's why we assembled a panel of some of the smartest engineering leaders we know at Interact to talk about the leadership principles that help guide an engineering organization no matter what is happening in the world. Today's episode of Dev Interrupted features Michael Stahnke, VP of Platform at CircleCI; Lewis Tuff, VP of Engineering at Blockchain.com; and Carolyn Vo, Partner & Head of Engineering at Oliver Wyman. Episode Highlights Include (2:16) The current economic climate (8:50) Engineers complaining about too many meetings (14:36) Maintaining morale (22:43) Building a culture that's actually fun (27:40) The importance of experimentation (34:36) Owning your own message (41:44) Seeking out mentors (44:13) Acquiring new top talent (51:00) Is now a time to be more or less aggressive when hiring? Episode Excerpt Conor: So let's start by getting to know you all a little bit better, make sure our audience can understand the context of who you are. Lewis, I wanna start with you. You're the VP of Engineering at Blockchain.com. How is the current economic climate affecting you? Lewis: Sure, great question. This has definitely been an exceptional year for a different macro and micro impacts and events on all businesses. For us, in the crypto currency industry, we've been building and preparing for this for a long time. In the last kind of decade, there's been a lot of challenging volatility in the markets, in the industry, whether it's kind of regulators or countries or big entities coming out saying that it's doomed to fail. And I think now they've reported many, many times over the last few years that Bitcoin is dead and it continues to bounce back. So I think for us, we've been kind of preparing to diversify our technology stack, our products, and also set expectations as a team that it's not gonna be a smooth ride and rarely that of when you're building new technology and pushing boundaries is it kind of a linear path, right? You're always gonna take a more complex direction to get there and so really it's about focusing on core product, focusing on the value that you're creating for your users, understanding what it is that provides utility and making sure the team is kind of really brought into the long-term mission. Conor: That makes sense and I think it's something that Michael can probably speak to as well. Michael, before you became the VP of Platform at CircleCI, I know you were at Puppet for eight years. You've been on that forefront of building new technology and innovating. What have those experiences done to shape your leadership style today? Michael: Well, I mean, I think a lot, I look at a lot of it about who are the customers you're selling into and what are the problems that they're having. You know, it always starts with if you understand what your customer is trying to accomplish, then you can probably help them achieve their goals and that's gonna really kind of soften the blow for whatever's happening for your company or help it or you know, whatever, I guess. If you remain customer-oriented, I think you, you're gonna do the best. Now, the issue is, you know, you have to figure out, "Am I helping existing customers? Am I trying to attain new ones? Am I helping a certain vertical more than another?" So there's a lot of nuance in there, but I think, you know, as I look back at the last 10 years of working in developer tools in one way or another, efficiency doesn't go out of style and so, you know, people wanna be more efficient, they wanna be more productive with what they have and so you have to kind of focus on how can you show that to your customers and how can you really double down on that? I think when the economic times aren't so certain, you have to kind of say, "Okay, we're gonna focus and we're gonna peel back on maybe some of the bigger bets that we were gonna take. We're not gonna do every bet or every little small bet. We have to stay a little more focused." And it kind of comes back to, you know, you can do everything, but you can't do, you can do anything, but you can't do everything. Lewis: I think that, just to echo that, I think that's a great point that really what these environments do is act as a forcing function to focus on the truly highest-impact endeavors. And so like in like a very flush bull market where venture capitalists and public markets and everything is going up, you will take a lot of the weird and wonderful best experiments and that also breeds inefficiency because there's no need to optimize, and so, yeah, for us, that's been like a big effort over the last few months is to really just kind of, yeah, peel back the layers of complexity and understand, okay, what is the most high-impact projects we could be working on and where are the inefficiencies and how do we better deploy every dollar within the business, whether that's in the team, whether that's in new technology like Circle CI to like optimize some of our developer experience or whether that's actually just cutting off kind of inefficiencies that we're left to breed. Conor: And Carolyn, I'd love to get your perspective on this as well. You're a Partner at Oliver Wyman. You kind of have a unique perspective on this panel. You came up through the engineering org there and have grown in your role. What kind of has that progression, your experience, taught you about this same topic? Carolyn: So the nature of the work that we do in consulting, right, you sometimes can have like the feeling of feast or famine when there's uncertain economic times because your work, your workloads and the type of work you get from clients' needs and demands fluctuates based on what the economic trends are looking like, right? And so you basically have to just go with the flow. It's just interesting, right, because if you normally see a lot of like advisory and build demand in normal standard economic times, okay, great, and then when things are facing like an economic downturn, companies are tightening their belts and they're being much, much, much more judicious about what they do with their spend and their budget. And as a result, you'll see the nature of the work and the needs and skills just kind of shift. And I feel like I've been able to sell, be relevant, we'll call it, as an engineer in a management consulting firm because I do both oversight of the delivery stuff and the build stuff as well as the advisory stuff. I don't know, it's just, I'm not sure if I'm answering your question, but it's just, it's such a strange different business model from a typical product engineering or services or platform kind of place, right? Conor: No, I like that we're getting these different perspectives because I think it's a really important thing to point out. This can be different for every business, right? Like, okay, sure, you may be need to focus on core products as Michael and Lewis are alluding to, but there are service models that have nuances to them and I think understanding that and understanding that not every person in the audience has the exact same approach and you need to kind of adapt it for your business and your team is really important. And I'll say one of the things that I know all of you deal with to be successful in this is communication with your teams. It becomes extra important in these, as we call them, uncertain times, to make sure your team understands where you're going.

I never liked being on-call (slight understatement) or asking others to shoulder some of the load. Sometimes it feels like it's a penalty for being more involved and knowledgeable about our code and infrastructure. And it definitely is a big distraction from core development and innovation. But there really is no way to avoid it once you have a live product or website with paying customers. Somebody needs to be available just in case something goes wrong. How on-call is done in your organization or by your prospective employer can make all the difference in your success (and sanity). Here are some approaches I’ve seen that can improve the on-call experience and overall productivity. Wake Up R&D! Being woken up in the middle of the night due to the NOC or support team opening a high severity ticket, only to find out that it was a relatively non-critical issue absolutely sucks. To solve this all too common scenario, one company I worked at came up with a simple solution. They replaced the “High Severity” designation with “Wake Up R&D.” By clearly outlining the result of opening a high severity ticket, they forced the opener to think twice (maybe even thrice) about whether the issue was really worth waking someone up in the middle of the night. Main Takeaway Make sure that you or your prospective employer has a good method for separating the signal from the noise. Junior and New Employees For junior or new employees who might be unfamiliar with all the intricacies of what constitutes a critical issue, how it should be handled, etc., it’s essential to have a runbook or some other documentation that outlines what issues warrant waking R&D up in the middle of the night. While this type of documentation goes a long way in describing various scenarios, their severity and how they should be handled, it takes a few months for someone to get a sense of the systems they’re working with, and be able to classify incidents accurately. Main Takeaway Make sure that you or your prospective employer invests the time and training for newbies to ease them through this learning process. The Fifth DORA Metric Well, it might be the sixth Dora metric as Google added a fifth already in 2021. Either way, hat tip to Charity Majors, CTO at Honeycomb who suggests in this excellent blog post that software engineering management should be evaluated not only by the four original DORA metrics but also by how often their “team is alerted outside of working hours.” This makes perfect sense to me. Management must do their utmost to ensure productivity. Why do I make this bold claim? Well I can only speak for myself but if I am feeling stressed about my upcoming on-call duties, I won't be focused on my work. If I’m tired the day after on-call, I won’t be sharp and creative. If I’m feeling overworked and underappreciated for my core contributions, I will be less motivated to give my utmost effort. Main Takeaway Make sure that you or your prospective employee respects employee overall well-being and understands that on-call duties can be very draining. The Fear Factor Earlier in my career, I’d go through many emotions during on-call incidents. How will I be judged if I don’t know how to handle the situation on my own? It’s 2 a.m. — what if I’m totally off, and this is not an issue at all? Do I want to risk the wrath of the senior expert I barely said two words to since I joined the company? These and many other thoughts would race through my head, and no matter the time of day or night, I was fortunate to have a close working relationship with my direct manager and would ping him whenever I was really unsure of what to do. As CTO at Kubiya.ai, I try to create a healthy balance. Waking a teammate in the middle of the night should obviously be avoided, but at the same time is totally fine provided we did everything we could to solve it on our own. And even if it turns out to be a false alarm or some easy fix, I say better safe than sorry. But this takes coaching and publicly stating to the team that this is our approach so everyone is on the same page and no one is terrified of making the call. Main Takeaway If you are building your on-call structure, clearly communicate that we must try and avoid waking colleagues, but at the same time, it’s perfectly acceptable if we need to (and even if we are wrong, it’s ok too). If you are evaluating a prospective employee, try and gauge what their culture is like and ask how they address this issue. Emotional Intelligence Technology teams are not known for their outstanding communication skills. And when you throw in a tense, sev 1 situation, I’ve seen people on-call think they have tracked feature ownership correctly and unfortunately when they reach out to the “owner” it comes across as super accusatory. They approach a developer with a buggy piece of code that seems to belong to them. They will be like “hey your code is causing the app to crash, blah blah,” and all of a sudden, the developer has an important meeting and cannot help — or worse, gets super defensive and mouths off. So it’s super important to avoid any accusatory or critical tones and/or wording when you think you’d found the issue and the person who can help. It’s really hard to know if it’s the specific code that is at fault. Maybe it was a change in firewall configuration, or perhaps it was a related but different component that is causing the issue. Refactoring code can also make it look like someone was the author even though they are not. Plus, if someone wrote something over a year ago and there were many iterations, it will take them some time to dig back in and understand. Main Takeaway Always be humble when raising an issue. Don’t jump to conclusions or blame anyone. Just ask for help, suggestions, and ideas from the people you think might be able to help. Let them know that while you are not sure they are the right address, you thought that perhaps, because they were involved at some point with the code, they could help. Who Should Be On-Call? This is really a tough question, but in my experience, operations teams should always have someone on-call. That said, if operationally things are very stable while applications are not so stable, developers might need to be the regular members of on-call rotation. In smaller companies, devs should probably have ops capabilities anyway, so they can cover all issues. Of course, during critical releases, particularly new features, devs should be on call. Main Takeaway Try and make sure that your teams are well-versed in all relevant areas to the extent possible, but obviously, this may not be realistic. So identify where the system is weakest and allocate on-call accordingly. If you are evaluating a prospective employer, try and see whether your role (dev or ops) would carry the brunt of on-call and make sure it’s reasonable and well compensated for. At the end of the day, on-call is the toll we techies must pay. But it’s worth it. Hang in there!