Coursera three, Engineering Management, course one, module three, setting your team's goals, starting with Lesson one, proposing goals for approval. Hello and welcome to our module on setting your team's goals and giving your team members purpose. By the end of this module you will learn, how to propose goals for your team, how to draft two common types of goals, the Amazon-style SMART goals and the Google-style Objectives and Key Results, abbreviated OKRs, and how to communicate your team's progress towards those goals. As I mentioned during the start of the specialization, engineering managers are responsible and accountable for two very basic goals. One, grow your engineering team and two, deliver on your commitments. In the previous module we covered, how you, the Engineering Manager, hire your team. Now let's assume that you've already hired your very own Two Pizza Team of seven engineers. Now we'll cover, how to set your commitments and track your progress on how close you are to delivering on your commitment. Let's start with, what are commitments? Commitments are goals that you propose and that your leadership approves. Once a goal you propose becomes a commitment, you are responsible and accountable for meeting or exceeding that commitment. You develop your professional reputation based on the difficulty of commitments you take and your track record on whether you meet them. Your leadership will review your proposed goals during periods called, planning cycles. Planning cycles occur regularly, for example, once every year. So every year, during your planning cycle, you must propose a new set of goals to explain what your team will do for the next year. Your goals help define the strategy for your team. A strategy is a set of long term objectives for your team, which might take a year or longer to achieve. The opposite of strategy is tactics or the short term actions you lead your team to do every month, week or day. An example of a tactic is, Agile software development. We'll cover tactics like that in the next module. Having commitments is very important for three reasons. First, your commitments tell the members of your team what they can look forward to during the long term, so that they can prepare themselves. Second, your commitments inform your leadership and other teams of your long term plans. Your leaders can incorporate your team's plans into the entire business goals, whereas managers of other teams can propose cross functional goals, connecting their goals with your goals, because both teams working together can deliver more than the two teams working in isolation. Third, and just as importantly, it tells everyone from your team members to other teams, what your team will not do during the long term. This decreases the probability that leadership or other teams can randomize your team with unplanned tasks. Now, let's talk about four ways to categorize goals. Top down goals, bottom up goals, cross functional goals and team goals. The first type of goal is a top down goal, a top down goal comes from your leadership and requires you and your team to accomplish it. You encounter top down goals frequently throughout your life. An example might be, you must maintain a grade point average of 3.0 or above in order to remain in the program. This goal applies to you and to everyone else in your program, no matter what their particular interests or which courses they elect to take. A top down goal at a software engineering organization might be, everyone in the organization must complete our annual security training. As a manager you are responsible and accountable for all of your team members, finding the time and the effort that's needed to complete this training. If just one member of your team does not complete the training, your organization's leadership might come to you and ask why. The second type of goal as an individual or bottom up goal. Individual goals reflect your personal interests and desires, but might have minimal impact on others around you. You set individual goals for yourself all the time, an example might be, I want to complete this Coursera specialization by the end of this month. A bottom up goal at a software engineering organization might be one of your team members asking you, if they can build a feature. As a manager, you should complement your engineer for their initiative, but also evaluate whether the time and effort spent on this bottom up goal might negatively impact the rest of the team before saying yes
