eng mgmt ep4: Goal-driven development
This is episode 4 of my series on being an Engineering Manager (1, 2, 3, 4, 5, 6, 7, 8). Herein we articulate the purpose of life. And how to measure it.
Why do we do what we do? What is this life for? We are driven to solve amazing, complex problems. Ours are challenges of 0s and 1s, of virtual armies of nodes, of pixels and bytes and Hayes-compatible modems. We flourish in this space, and we are changing the world. We want to create and innovate and disrupt and erupt. If we win the lottery, we will still do this work — even when no one is paying us.
But for now, someone is paying us — often, much more than is reasonable. So let’s make sure we are earning our cheddar. As an engineering manager, an important part of your job is communicating to the business what the investment in your team is yielding, what you guys are accomplishing for the business, and demonstrating that you and your team are moving as successfully as you can.
With what language should this communication happen? Goals.
Why goals?
Doing something good is good. Doing something great is great. But saying ahead of time what you are going to do, and then doing it? That’s even better than great. When Muhammad Ali called his Shot Heard ’Round the World, and then won Super Bowl VII with a walk-off three-pointer, it was legendary because he broadcast his goal ahead of time. Or maybe that was Babe Ruth at the World Cup.
The same thing goes in business. Businesses thrive on predictability. Whatever greatness is coming out of your team, you need to set expectations for it. Hiding in a conference room for six months while you work on a super secret mission is fun — an occasional skunkworks project can be useful, particularly when you don’t know what the outcome will be. But as a leader in the organization, your job is to visualize and socialize your team’s goals ahead of time, and then drive to those successes. You need to prepare the business for the magic you are making happen. You need to paint a picture of the beautiful future that your team will bring to life.
The reason for this is: you and your team are not operating in a vacuum. Whatever work you are doing will impact other teams, the customer, the user. If you’re building a new feature, Product Marketing needs to start developing their rollout plan for customers. If you are working on a performance overhaul, Netops might need to adjust resource planning in their budget. If you are building a new mobile app, QA will need to ramp up their test fixtures ahead of time. Whatever you are doing, someone else is affected. (If no one is affected, then you are wasting your time — don’t do it!)
Goal frameworks
Hopefully your company has some methodology for defining and tracking goals. Most of them are pretty similar; what matters is how they are used, and that they are treated with significance. If your company doesn’t have something like this — guess what! You can be the one driving a strategic initiative to make your company more goal-oriented. Growth opportunity!
I am partial to Google’s OKR framework these days. Here are the main aspects that have worked well for my teams:
- Quick cycle time — we do quarterly goals; trying to predict beyond that won’t work at a fast-moving startup.
- Small and focused — any one person shouldn’t really be thinking about more than 2 or 3 big things in any goal cycle. More than that and you end up compromising some to achieve the others.
- Aggressive — goals should not be easy. Easy goals don’t build a strong, successful organization. No one should be achieving 100% of their goals 100% of the time — if they are, they are not being aggressive enough.
- Public — anyone should be able to see anyone else’s goals, and how they did on them! If not, then the goals don’t have any teeth. A secret goal is a useless goal. The accountability of writing in a public space “I’m giving myself 0.6 on this goal, because…” is elemental. Plus, public goals help everyone know what everyone else is thinking and worrying about — facilitating communication across organizations.
- Measurable — this is critical. This is so important, I am going to type more words in a section called “Why goals must be measurable.”
Why goals must be measurable
Let’s start with a silly example. Sales goals are ultimately metricized — salespeople have specific revenue targets, measured with a popular unit of business: “Dollars”. Imagine if a sales team didn’t use measurable goals, and instead used qualitative goals:
Boss: “Jensen —your Q3 goal was ‘Pretty Good Sales’. Where do we stand against that target?”
Jensen: “Golly, boss, I’m doing great! I just closed the Initrode deal for Some Revenue.”
Boss: “Jensen, that only gets you to Good Sales. You’re way off target, and it is nearly October!”
Jensen: “B-b-b-but boss! I thought these sales were Pretty Good!”
Boss: “You’re fired, Jensen!”
Don’t be Jensen. Don’t get fired. Non-metricized goals leave too much room for subjectivity and interpretation. You may feel like you’ve knocked it out of the park on your goals, but guess what — that doesn’t matter! What matters is that the business feels that way. The good news is that with metrics set ahead of time, you can make sure that the business indeed feels the way you want them to. Maybe $100k is an aggressive target for Jensen. Or $1M or $10M. Whatever the right target is, Jensen needs to set it ahead of time, to make sure the business agrees that achieving it is a victory.
Setting measurable goals is harder in software engineering, where positive outcomes aren’t always as easily converted into a linear scale like dollars. This is a skill that you must hone. As we discussed last ep, this is particularly critical for technical work that necessitates business justification. But all the work your team does, every outcome they are marching towards, should be articulated in terms of measurable goals. Doing so allows you to ensure ahead of time that your team’s achievements will be meaningful, significant, and rewarding.
So, how to set Engineering goals? First, how not to set them:
Features aren’t goals
Suppose your entire team is focused on a collective mission to build a specific feature — say, a paperclip that talks to you. And, say the entire company is in complete alignment that the paperclip is an important feature, that this is the right direction for you and your team. It is tempting to simply articulate your team’s goal as “Build a talking paperclip by July 1”. Since everyone agrees that this is the right thing to do, this must be a great goal to have, right? Nope. It’s not.
“What?” you say in shock, as if the barista had just told you they are out of almond milk. “How is that not a great goal?” Because — the existence of a feature is not an achievement. Customers, executives, boards of directors, future résumé readers don’t care that a feature exists. Ten years from now, when you are gunning for the CEO role at Compucorp Incorporated, they aren’t going to care that you built a paperclip. They are going to care how you moved the business forward. What moves businesses forward is the impact the feature has. So that is what your goal needs to focus on.
Your job as a software engineering leader is not to deliver features — leaders who have that mentality are forever encumbered by it. Your ownership of the business’ outcomes doesn’t stop at “the code compiled” or “the release went out”. You are responsible for how that code breathes, improves the lives of users and customers, and adds value to the business. So when you and your team sign up to build a paperclip, your goal needs to be wrapped around what that endearing little paperclip guy accomplishes. Is he increasing user satisfaction? Is he reducing customer support ticket volume? Is he causing people across the world to smile with delight? Whatever it is, that is what your goal needs to be focused on. The feature is a delivery vehicle for business outcomes. And you need to own those business outcomes. And those business outcomes are measurable — always.
This is hard — it can sometimes seem like some parts of that ecosystem are beyond your control. But this mode of thinking has the advantage of forcing you to focus on the business, not just the technology. That focus of yours will permeate your team, and outsiders will see how aligned you and your team are on the business. This is powerful, and imperative for your leadership growth.
Okay, smartypants, if features aren’t goals, what should my goals be?
That’s the million dollar question, and one you need to figure out. As an Engineering team, you typically will have objectives via business initiatives, and hopefully some technical initiatives as well. The good news for the business initiatives is that there is a whole team of experts whose job it is to define the business outcome of your technical work: the Product Management team. They will be able to clearly articulate the impact of the work your team is doing, and therefore you can partner with them and adopt the metrics they are defining as your own measures of success. Your metrics should also include the technical outcomes of your work (“zero customer-identified bugs” or “sub-100ms search” or whatever other technical measurements are relevant), but must include some set of business outcomes.
The measurements discussed above and last episode are often great ways to assess the outcome of work: revenue generated, users served, efficiency, performance, scalability, user happiness, number of support tickets filed, etc. The more straightforward and obvious an outcome is, the more easy it will be to describe that impact to the non-technical side of the company (and, be a great bullet point for your résumé). At the end of the day, you want to be able to explain to the CEO of the company what you are shooting for, how you are measuring success, and how it affects the business. Keep that in mind when setting these goals!
Why each team member should own some goals
You, as the leader of your team, will be the primary author of your team’s goals. This is important, since its your job to market them to Sally over in Product Management and Jensen in Sales (if he still works there). You need to make sure they align with the company goals, and that your boss feels good about them, and so on.
It would be easy to define the goals and then proclaim, “Behold — our team’s goals!” and leave it at that. Your team would warmly welcome this well-developed plan, and would dive right in to achieve these goals by the end of the cycle. Recently I read some blog post that was advocating for exactly this: the entire team should share the entire set of team goals. I think that this is exactly wrong, and here is why:
- The bystander effect: If everyone shares this set of outcomes, it is very easy to fall into the trap of no one feeling personally responsible for any particular outcome. Thus, each outcome will have no one thinking specifically about it, increasing the risk of it not being achieved. In general, the best way to ensure that a piece of work gets done is make it someone’s full time job, and the converse is generally true too. Mild failure on each outcome means massive failure on the set of outcomes.
- “Management” != “The keeper of the business outcomes”: Though an important part of your job is to insulate your team from the administravia and clerical business randomization, this does not apply to business outcomes. Your team needs to be as in touch with the business impact of their work as you are — otherwise, it is very easy for their technical work to become misaligned with the business. Signing up a team member for a business outcome, versus a technical outcome, increases the odds that you’ll achieve those business outcomes.
- Engineers need ownership: For engineers to grow their careers, they need to be able to demonstrate positive business results from their work — just like you do. In other words, Architects own business goals just as VP Engs do. So, it is your responsibility to foster the opportunities for your team to grow this skill. Individual ownership of goals still allows for collective wins: when a team member of yours achieves an important business goal, this reflects just as positively on you — since your job is to foster a playing field for their successes.
- Delegation is critical in leadership: If you are the only one thinking about the business outcomes, you won’t be getting a lot of sleep. Keeping all those plates spinning is hard — you need to spread the love, so that other people are stressing too.
For all these reasons, I am a huge advocate for individual team members owning individual business goals. As you draft your team’s goals (ideally, with your team), you should be explicitly assigning these goals to team members.
An example of this, using OKRs, would be to have each team KR become an individual’s O. Then that individual can design the KRs that achieve that O, and then all of the team’s completed KRs will achieve the team’s O’s. This empowers the individual to define their own strategy towards their Objective, thusly crowdsourcing the entirety of your team’s OKRs.
The key thing about this is: Just because Sally owns a specific business goal, doesn’t mean that Sally is the only person working on that goal! Anyone/everyone could work towards the goal, but Sally is the backstop. She is owning that goal and is responsible for keeping an eye on it and pushing for it and tracking it.
How you should utilize your goals
Okay, it is day 2 of the quarter, and you are sitting on a nice set of goals that you have committed to achieving. What do you do now?
- Strategize how you’ll get there — You need a plan: a division of labor, and technical roadmap, a high level technical design, a kanban board of open tickets, whatever. Whichever mechanism your team uses to plan and track work needs to be populated with the plan that will get your goals achieved. Set up brainstorms or planning discussions, assign out specific goals for technical design, do a backlog grooming. Make sure you can see how the team will get there, and make sure you feel it is aggressively but realistically doable.
- Make sure everyone is marching towards that victory — All of the work projects or Jira tickets or technical designs that people are currently working must fold into these goals. If someone is working on something that you can’t directly attribute to a goal, perhaps it should be deprioritized? Or maybe you missed an important goal? Your goals should define the entirety of work your team is doing. If there is work your team does that doesn’t seem important enough to have a goal wrapped around it, maybe it shouldn’t be done at all? If your team stops doing that work, what breaks? Is it a problem if it breaks? And think about who cares if it breaks — perhaps that person should have a goal around that.
- Think about your goals daily — Since these goals are how you will be judged in three months’ time, they are worthy of recurring consideration. If you haven’t actively thought about them in a few days, revisit them. Think about your team’s work — are things going well? Since the goals are metricized, are you seeing those metrics improve? Generally it is not good to have metrics that will be at zero right up until the final day of the quarter when all the work is done — that is a huge dice roll: if you miss that last delivery, you get zero percent on it. That’s a royal F.
- Use your goals to manage your own time — If your goals have a clear priority, then so to should your allocation of your time across your goals. If your most important goal requires none of your time, that might be wonderful. But be really sure of that, since if it falls apart, you will take the brunt of that failure. Make sure you are applying your time to your goals — if you find you are spending time on things that don’t contribute to your goals, fix it.
- Grade your goals — At the end of the cycle, everyone should grade their goals. This should be done in a public fashion, so that everyone can see how the team did. This is as simple as writing a sentence like “Giving myself a 0.8 on this goal, since the last part of the project didn’t get completed on time”. This will help train the team that intellectual honesty trumps getting straight A’s — which is critical to avoid a false sense of success.
- Factor your team’s goal performance into their performance reviews — If your company has a well-developed goal tracking system that is treated with significance, writing performance reviews gets really easy. You can throw out the old-style authoring many paragraphs of flowery language to describe yourself or your reports. Thank goodness! Performance reviews then simply become a revising of each person’s goals and results from the past year. These were the business metrics that matter, so a person’s performance review should be based on them. No more subjectivity, no more struggling to remember what happened eight months ago — it’s been planned, tracked, measured, and graded. Now, goals shouldn’t be the only thing that is factored into a performance review — a person’s overall performance also includes intangibles like cultural impact, mentorship and team-player-ishness, attitude and ambition, and plenty of other of aspects of a person’s life at a company. But goals are a big factor— so save yourself some time!
Best of luck in setting and achieving your goals! Jump to the next episode, where we’ll talk about of one the most important goals in a growing business: recruiting!
Photo credits: Ferdinand Stöhr, Inja Pavlić, Brooke Lark, Mario Purisic
Eng Mgmt series by Matthew Vanderzee
- eng mgmt ep1: Should I become an Engineering Manager?
- eng mgmt ep2: What should I do today?
- eng mgmt ep3: Making tech things happen
- eng mgmt ep4: Goal-driven development
- eng mgmt ep5: Recruit great engineers or die tryin’
- eng mgmt ep6: Growth-oriented leadership
- eng mgmt ep7: Am I a good manager?
- eng mgmt ep8: So you want to be a Director (Quiz Show edition)
