Using Stretch Goals

In the chapter on “Setting Clear Expectations,” we talked about the need to set clear and reasonably objective expectations so that your employees knew what was expected of them. This is important for setting a baseline of expected performance, but when you’re looking to develop and grow your team, you’ll also want to have some goals that stretch beyond just what’s expected, and push your employees out of their comfort zone.

Embrace the snake! As a leader-of-leaders, I once had a team leader of a research/prototype project who came to us with little to no technical background. She’d always wanted to explore programming, but never really had the support to do so. Curious, and wanting to see if I could find a few like minds, I found that on my team no less than four other people—including one of our developer advocates, a technology community manager, and my administrative assistant—all wanted to learn something about programming. The stage was set, all I had to do was push the players onto it, so I did: I used company funds to buy each of them a copy of a book on Python, set them up with subscriptions to an online educational system to give them a formal class outline to follow, had them set an hour aside every week to meet and talk about the language, and then met with each of them once a week to find out how it was going. As of this writing (long after I’ve left the company), I’m happy to report that all of them now have some level of Python skill, and it’s helping open doors for each of them in ways that they hadn’t anticipated.

As a manager, you are in the perfect position to set some “stretch goals” for each of your employees that will help them achieve their longer-term goals beyond just “earn a living.” Use your 1:1s to find out what their career paths look like, and do a little imagination-exploration: Forget the here-and-now. What do they want to do? Where do they want to go? What sort of things would they love to do, but have no idea how to accomplish?

Goals differ from expectations, by the way, in that goals can be failed without creating a problem. In fact, as we’ll examine more in the section on “Challenges,” your employee should fail a goal or two—if they don’t meet with failure somewhere along the way, it’s a sign that you’re not setting the goals far enough away to stretch them. Think back to when you’re in the gym: If you want to get stronger, you have to lift more weight, not just the same weight over and over again. If you want to get faster, you have to run farther and at greater speed, or you’ll never improve. You don’t always manage to lift the greater weight, and you don’t manage to always run fast enough to hit the new time, and that’s OK, there’s always tomorrow. Same story here—your direct might not hit their growth goal during this performance cycle, and that’s OK, there’s always next cycle.

Use what you get out of those 1:1s to then craft a “growth plan,” and set goals that help them accomplish that plan. When creating these goals, look to make them:

• Aligned to the company’s strategy and company-beneficial. Yes, they’re your employees goals, but if you can align the goals to both individual and company strategies and benefits, the company will be support them.
• Specific and measurable. Vague goals serve nobody well. Make the goals something that can be “checked off” when they’re done. Don’t just “learn Python,” choose instead to “Write a Python program that can convert temperatures” and then “Write a Python program that can read a directory of files and put that data into a database” and so on.
• Framed in time, with clear deadlines. I call these “forcing functions,” because often the deadline is entirely self-administrated, but equally often it ties into a company goal. “Write a Python program to automatically generate weekly status reports from information posted to GitHub starting on September 1” gives your employee a target date, and lets them “work backwards” to figure out when they’ll need to have certain steps done.
• Achievable but challenging. We’ll talk more about challenges in the next section; on the whole, though, if it’s not pushing your employee out of their comfort zone a little, it’s probably not going to seriously “move the needle” on or further that individual’s career.
• Future-focused. Looking into the future means looking into the individual’s desired future as well as that of the company’s. It means knowing where you want to go, and having a decent idea of how to get there. If it’s not clear to either of you, you either need to do some research to figure out how to get there, or you both need to work to refine and clarify the picture more.
• Tailored to the individual employee. I got lucky with my team in that there were five people who all had future directions that lay on the same path for a while, so I could organize them into a study group/book club. Each had their own long-term vision, but for a period of time, each wanted to take the step of learning Python. Make sure the goals you and your employee set match the desires of the individual.
• Documented and not forgotten. This is on you, as the manager: Capture the goals, write them down, and make sure to bring them back up as part of your 1:1s and performance reviews from then on. Too often these goals are just written down and put into a file folder until the next performance review cycle comes around—don’t be that manager. Make it clear that hitting these more strategic goals is every bit as important as hitting the other, more tactical, goals.

When thinking about sources of goals, consider the “magic triangle” of software projects: “better, faster, cheaper.” What kinds of things can somebody on your team create or deliver that improves one of those three legs of the triangle? “Better” can mean creating new features in a framework, or working to add some skill to the team. “Faster” can mean finding ways to encapsulate behavior into a reusable component, or building a tool to automate some aspect of the development process. “Cheaper” can perhaps mean “requiring fewer developers,” or perhaps “requiring no developers at all” by incorporating some aspects of low-code/no-code tooling into the process.

Not all your individuals’ goals will focus around better/faster/cheaper—that’s simply a means to inspire your brainstorming when discussing this with your direct report.

The more you can tie performance expectations to the goals of your employees, the more your team will feel like achieving those expectations isn’t just fulfilling company needs, but also fulfilling their career steps. Additionally, taking the effort to try and find ways to tie expectations and goals together will help you as the manager, because now your employees’ goals will be closer to the top of your mind, and that will help you recognize opportunities for your employees when they occur.

Story time! A daughter of one of my friends, who had just finished up a coding boot camp, approached me about job opportunities. She was struggling—she clearly needed more experience to be considered an Associate Software Engineer, and was having a hard time finding that “first shot.” I could see the diamond in the rough, so I talked my CEO partner into a deal. We hired her to do two things: first, work on a blog implementation for us (so that the company could use it as a web branding and SEO driver), and second, go through online training classes to improve her skillset in programming languages and platforms (in our case, C#). After two months, we’d evaluate, and if she’d gotten the blog off the ground and could demonstrate some expertise with C#, we’d promote her to ASE and put her on a team. It was a touch unusual in that it was a very short-term setup, but the focus was on setting the clear expectation of what we needed her to do, complete with some measurable results (did the blog work? was she getting through the lessons?) that were under her direct control. The goal was to get her on to a team, and the expectations were set to help her reach that goal. Six months after moving her to one of the teams, her team lead came to me and told me in no uncertain terms that if I took her off of his team, he’d quit. She’s a Senior Software Engineer as I write this.