The third type of goal is a cross functional goal. This is a shared goal proposed by you and one or more other managers. Cross functional goals at large engineering organizations can involve many, many managers. As previously mentioned, the reason you take a cross functional goal is to pull all of your engineers together across different teams to accomplish something that your team alone cannot accomplish. You can also take cross functional goals with other managers because if you don't do so during the planning cycle, some of the managers you need might already have committed their teams to other goals. Or simply their own internal team goals and be unable to help you. The fourth and final type of goal is a team goal. The process for drafting your team goals is as follows. One, draft your goals based on what is the most important to you to accomplish with the software you own and your customers. Two, seek approval of your goals from leadership and three, upon receiving approval, translate your approved goals into individual goals for each engineer on your team. Have you ever drafted team goals before, whether you have drafted team goals or not, let's all work from the same set of team goals. In this graphic, you see an example of proposed team goals. Let's suppose that you submitted this list of goals for your seven engineer team. Now, let's further suppose that today is the day your leadership is going to review your goals for approval. The first blue goal reads, core operations, three engineers. The second red goal reads, Launch feature A, four engineers. The third goal which is also red reads, Launch feature B, five engineers. The fourth goal which is in blue reads, Refactor existing systems, two engineers. It's important to say that while the review of your goals for next year is happening today, the goals we're looking at are for what your team will do next year. This year, you are responsible and accountable for meeting the goals that were approved last year. After seeing this list, your first question might be, I have a seven engineer team. Why then am I proposing goals that add up to 14 engineers? 14 engineers is double the amount I actually have. The reason is that you draft goals to indicate what you believe your team should do next year regardless of resource constraints. It's up to your leaders, the people who review your goals to determine whether to fund your goals. For example, if your leaders agree that you should launch feature B, they also agree that you need to hire five more engineers onto your team. If your leaders agree to all the goals you proposed, they agree that you can double the size of your team. In this way, you've also taken on the additional goal of hiring more engineers so that you have enough engineers to deliver both goals as proposed by next year. Another good question you might ask is, how do I know the number of engineers I need to accomplish? Each goal, next year is correct. This question has to deal with project estimation, which is the discipline of analyzing data to predict the time, cost and number of engineers needed to complete a project. Academics have proposed many project estimation techniques with grandiose names like parametric modeling or program evaluation and review technique or even planning poker. In the software engineering field, project estimation is less convoluted. You just use common sense and experience. Look at how many engineers it took your team or a similar team to complete a similar goal. Think about why your current goal is different and estimate how many engineers you use to accomplish their goal. If you're a new manager or have just started managing a new team, you might lack the estimation knowledge of your leaders and colleagues. In that case, you can look at historical information or ask other managers to cultivate your own sense of project estimation. Experienced managers and leaders have a very clear understanding of how many engineers you need to complete a project by a particular time. Sometimes during goal reviews, a leader will see a goal for the first time. Tell a manager they need more or fewer engineers to accomplish a goal and adjust the number of engineers for that goal on the fly. At this point, you might be wondering who these leaders are. The leader could be anyone from your supervisor to the CEO of your company. It also depends on how impactful your goals are to the rest of the company. Later in the specialization, you'll learn about how Bill Gates personally reviewed and approved goals at Microsoft during the 1980s. If your goals are very important to your company, your company's CEO might review them too. Your third question might be, why are my goals outlined in different colors? The red goals are goals to build new features. A new feature is new functionality, meaning that your team will write, review and deploy brand new code. In software engineering, the effort of building a new feature is called development, abbreviated Dev. The blue goals are to maintain and improve your software's existing functionality. Maintaining functionality is part of the first goal, core operations. For example, you must dedicate some of your team to respond to emergent security incidents and urgent customer questions. Since many software companies have customers around the world, this means potentially getting paged anytime day or night. However, having your software at work is usually the most important for both your software and your business. And you must allocate enough engineers here before you can staff other goals. You can also improve your software's existing functionality by rewriting the code to be more efficient. Use fewer resources or require fewer engineers to maintain in the future. This is the last goal on the list. To re factor existing systems and reduce technical debt, maintaining and improving your software's existing functionality is called operations, abbreviated Ops.
