A combination of Dev goals and Ops goals is evidenced that your team practices DevOps. Meaning that each engineer on your team spends time on development and sometime on operations. To be clear, to follow the DevOps model, you don't assign the same three engineers to go on call and resolve emergent issues all the time. Rather to practice DevOps correctly, you rotate every member of your team, including yourself, the manager, to all take turns going on-call. On-call can be difficult and potentially involves getting a page about an emergent issue at any time, including at 3:00 AM in the morning. Why would you subject yourself and your team members to that experience? Because many decades ago and some companies still do this now, most software accompanies split their development and operations into two different organizations. For example, an American software company might perform all of their development in the United States, but outsource operations to engineers in a lower-cost country. An engineer working at that company would only practice development or operations, but not both. The engineers performing development could only hear about customer issues and fixes second-hand. The engineers performing operations could not apply their knowledge of customer issues to build new features. Then some companies try rotating the same engineer's between Dev and Ops, inventing DevOps. How much does DevOps improve the performance of your team? According to a DevOps trade group and also Google, the software engineering managers who reject the separation of Dev and Ops and who practiced DevOps make code deployments 200 times faster, recover from incidents, 2,600 times faster, and experience seven times lower failure rates than those who don't. In general, committing to operations goals and making everyone in your team responsible for core operations and emergent issues is the engineering best practice. The drawback to taking this goal is that your team and you have to go on call rotations and occasionally receive pages outside of business hours. However, the benefits of doing so are substantial, including to your team members development of software engineering skills, that many engineering managers decide that following the DevOps model is worthwhile. Now that we understand what the shortlist of goals mean, let's go back to our hypothetical. These are your goals and you've presented them for approval to your leadership. Do you think your leadership would approve these goals? Probably not. Why not? Because it's not clear why you're doing any of these things, with the exception of core operations, which is required to continue your business. The four fundamental reasons why you should pursue a goal and the metrics you should always track as the software engineering manager are to increase revenue, to decrease costs, to gain or keep customers, and four to comply with laws and top-down goals. Let's say your leadership sends you back to justify your goals. After working with your product managers, finance team, and other colleagues across your organization, you go back to your leaders with the following justifications: You predict Goal 2 to generate $2 million at the cost of four engineers. You predict Goal 3 to generate $5 million at the cost of five engineers. You predict Goal 4 to save only half a million dollars at the cost of two engineers. However, it is also a requirement of your organization. This gives your leadership enough information to evaluate your proposed goals. Let's assume they agree with your engineer estimates and give you the falling feedback. All other considerations being equal, feature B seems to present a better investment than feature A per head of investment. Furthermore, although refactoring the existing systems gives the least return on investment, leadership approves of it because they required it as a top-down goal. This means your proposed goals are approved with the following language. The goal to launch feature A is moved below all of the approved goals and below the cut line. You are responsible and accountable for delivering all the goals above the cut line. You are not responsible or accountable for delivering goals below the cut line. Why not? Because leadership did not approve the four engineers necessary to launch feature A. Why do we even have a cut line? Why not just delete the unapproved goal? There are several reasons all having to do with this being the list of goals for you to deliver next year. First, if next year you're successful and deliver all three goals for that year ahead of schedule. Well, first off, kudos and congratulations. You have engineers available, and rather than having no goal, you can staff them on launching feature A. Second, if you don't deliver all three goals ahead of schedule, launching feature A is likely to become one of the goals you're asked for during the next planning cycle. Third, between now and the end of next year, there might be a major shift in your customer's needs, and they might suddenly need you to launch feature A immediately, then you can use that as an input to re-prioritize your goals. For example, with your leadership's approval, you can move your goal to launching feature A above the cut line and make room for it by moving your goal to launch feature B below the cut line To summarize, at this stage in the planning cycle, you have determined that next year you have taken the commitment of delivering the following three goals: core operations, launching feature B, and re-factoring your existing systems. To accomplish these tasks, your leadership has approved you to hire a team of 10 engineers. Since your current team only has seven engineers, you should start hiring three engineers and have them in place before next year begins. If you do not perform this hiring in a timely fashion, you risk jeopardizing your goals by not having enough engineers on your team to deliver. Congratulations, you've completed a planning cycle and received approval for your goals for next year. You now have a set of commitments to deliver. Your next step is to share your goals with your team and assign their individual goals. The work you'll delegate to each of them to complete the overall goals. For each goal, you might even assign one of your engineers as the goal owner, meaning that they have the responsibility to lead the goal to completion and report on its progress. This is an example of delegation, as we explained in our previous content, as a manager, you are expected to delegate responsibility for meeting goals, but you cannot delegate accountability for whether or not you meet your commitments. At this point, let's review our first goal, which is in full core operations. How do you know if you met your team goal of core operations at the end of next year? In our next lesson, we'll look at how to break down large strategic goals like core operations, into smaller, measurable goals that everyone can understand and work towards.
