Managing Management: Expectations Part 1
No Mr. Bond, I expect you to die!
Let me start by saying that there are many different ways that one might evaluate the performance of an employee. You may think about the impact their projects had, their contributions to the projects, whether they deliver what they promised when they say they will, and a metric load of other measures. What I’ve found to be most helpful is to evaulate someone based on how they performed against what was expected of them. This is admittedly very much in line with how Meta likes to evaluate performance, but I liked it so much that I brought it to Zwift when we had to re-evaluate how we did performance management. The reason I like this so much is because it gives you (the manager) a somewhat objective set of criteria that you can then say: “Well, did this happen? And if it did, was it what we thought would happen? And if it didn’t, why not?”. But the one key thing about managing someone to expectations is that you have to actually have those expectations created somewhere, and ideally for both you and your team, they should be written down, communicated clearly, as specific as possible, updated regularly, and solidified well before it’s time to decide performance. If any of those pieces are missing, they whole concept gets decidedly dodgy.
So, that means that when you get started managing a team, or a person, or whatever, a good first question is to sit down and discuss whether there are expectations set anywhere for the employee. If there are, amazing! If not, then it’s probably time to start. And it’s not super hard to start - basically the format that I usually start with is something like:
Achieve goal x by doing thing y within z timeframe.
And within that of course there’s a ton of nuance and complexity to fill in. Maybe your team already does OKRs or some other form of goaling. If so, that’s great, then you already have some sense of what goal x will be - you just need to figure out how your team or individual will contribute to goal x. If they’re an engineer, maybe they’ll build part (or all) of the thing that will make goal x possible. If they’re a designer, maybe they’ll redesign an existing feature or what not to improve x to its goal. If they’re a PM hopefully they’ll be helping the team or multiple teams figure out the best way to approach the problem and driving progress. If your organization doesn’t have goals or OKRs, then hopefully there is still some sense of priority or what projects everyone should be working on, and you can use the top priority programs as the goal. If that doesn’t exist either, then I’m somewhat out of ideas and I suspect there are larger issues afoot than team expectations.
Another piece that I sometimes will add in the middle of the above is: “As measured by w”. This is useful since it means you have to take some time to think about: “well, how will we actually know if we’ve succeeded” BEFORE it’s time to find out whether you succeeded. Getting to the end of a program only to find out that you forgot to build the part that would allow you to measure its success is a very loud sad trombone. AND, if you have goals or actions that are somewhat nebulous, like “Drive alignment and approval for something” - I’ve seen instances where at the end of the period, there is disagreement as to whether alignment actually happened and/or if there was approval. So the more specific you can be: “as measured by a successful meeting with some exec or stakeholder”, and then you can go debate what successful means and whether it means putting it on the roadmap or getting funding or just having a good meeting where the exec gives everyone a thumbs up, at least you’re talking and thinking about this well before you (the manager) have to stand up and say that your employee deserves great rewards because something happened.
Once you have the format dialed, rinse and repeat a few times, and you’ve got your expectations. Next we’ll talk about what to do with them.