Learning how to be a manager can be tricky. Many times I’ll talk with other managers and inevitably, at some point, the subject of a team member’s performance comes up. Let’s say we’re talking about a fictitious people of Mal the manager, and Don the developer.
“Don is a great guy, but sometimes he can get lost in the weeds and take way too long to solve a problem. What should take a few hours can take days, and it never seems like he is making any progress.”
“Have you talked to him about it?”
“Yeah, but it never seems to stick. It always seems like this is a constant problem we’re having with him.”
I often wonder if Don were to overhear that conversation if he’d be surprised. He might remember having some discussions with Mal about the timeliness of getting work done, but didn’t Mal remember their legacy code base was a mess?
Setting Expectations
I’ve found personally communicating expectations to your team members can be a tricky thing. Over the last few years, I’ve stumbled upon a helpful technique to help clearly communicate your expectations as a manager.
You ready? It’s a doozy: “My expectation is <insert expectation>.”
Wow! That seems really dead simple, because it is.
However, arriving at that fabled statement can be a little tricky. In my career, I faced a similar issue. We had a new team member who was struggling to get work done in a timely manner. It was his first time working on a larger team and larger codebase, and he was struggling. Months had gone by and it felt like things were not improving.
Looking back, as a manager I was doing a poor job of setting my expectations for him. Guess who fault that was? Yup, mine. So we’ll continue with our example case with Mal and Don and break down why.
Types of Feedback
When Mal gives feedback to Don, they basically can be broken down into two types of feedback: suggestions and course corrections.
Suggestions are pieces of feedback given without an expectation that they are followed. Suggestions are typically given in scenarios where the issue is non-serious. As a manager, the majority of my feedback is in the form of “suggestions” while I’m mentoring the team: “I would look at ABC library to solve XYZ problem.” “I find it helpful to step away from my computer for 10 minutes and then come back with fresher eyes.” Etc.
Course corrections are feedback given with an expectation that they are followed. Typically they are given to address specific issues that need to change. The term course correction comes from the Apollo missions when 80% of the time the rocket was not on course. At first, the NASA engineers almost scrapped the Apollo 8 mission because they couldn’t keep the rocket on course. It wasn’t until they discovered they could improve their measurement tools & issue dozens of small “course corrections” to guide the rocket to its destination.
I like the Apollo example because it demonstrates that: first, course corrections are important. Staying off course too long will lead to serious issues. Second, course corrections are expected, common, and individually they aren’t a huge issue. If they need to happen, it should happen with small bits here and there. However, if you avoid giving a course correction early hoping that it just rights itself, you’re just deferring and accruing a bigger issue down the road.
Let’s apply this rocket science to a little more down-to-earth (see what I did there?) example with Mal and Don.
Managers Can Struggle to Communicate
Mal is clearly trying to communicate “course corrections” to Don, and it appears the signal isn’t getting through. The problem is many times as a manager we don’t clearly communicate between suggestions and course corrections. What makes the problem even worse is normally when the stakes are higher, managers will soften the delivery of their course correction so it appears even more like a suggestion! Here are some examples of feedback Mal has given to Don. First, some honest suggestions:
“Hey, I noticed you were spending a lot of time trying to reproduce those API requests. Chrome has an awesome ‘Copy as cURL’ you can use to cut down on the time to reproduce those.”
“I just reviewed your pull request work-in-progress. I saw a blog post about using XYZ library to send emails, you should check it out. That’ll save you some time.”
Then, Mal switches to giving course corrections. This is something internally happening in Mal’s mind since he isn’t happy with the time things are taking to get done. He is starting to realize his expectations are not being met, and tries to give the appropriate feedback:
“Hey, I’ve noticed this task is taking a lot longer than we thought. Is there anything I can do to help?”
“I think Jennifer fixed a similar bug a few weeks ago, you should loop her in to see if she can help.”
“I was hoping to have this task done, do you know what part is taking so long to hang this up?”
Mal is trying to be a nice person and help clue in Don that “Hey, I don’t want you to feel bad, but this is serious.” Mal has already started to talk more candidly with others about the problem, but it isn’t so easy when talking directly to Don and Mal unintentionally softens the issue.
So who fault is this? It’s Mal’s fault. He is trying to issue course corrections, and his expectations are not being met. What Mal doesn’t realize is he is assuming Don will pick up on his expectations given the context of the situation. Here’s the thing: context is an awful thing to rely on, especially when it is implicit.
Setting Clear Expectations
The solution is Mal needs to change that implicit expectation to an explicit one. It can be a hard conversation, especially when the issue has gone on longer than it should have. However, I have faith in Mal and Don! This problem can be solved. He is the advice I would give to Mal:
Step One — Before meeting with your team member, clearly define your expectation and examples of how those expectations have not been met. Mal needs to do this before meeting with Don. Trying to understand your own expectations on the fly can be tricky. It’s much better to clearly think them out ahead of time so you can clearly communicate them.
In Mal’s case, I would think about the issue and come up with something like this: “My expectation is there is a certain amount of time a task or project should take and that we need to finish our work in that time.”
Now Mal thinks about that expectation and knows software development isn’t that simple. There are times when things take longer than expected. Mal thinks back and realizes that most of the time he has to go ask why things are taking longer. So he comes up with a second expectation: “If something looks like it will take longer than expected, my expectation is that you just let me know then, and not several days later, so we can decide how to adapt.”
Great! Now Mal is ready for…
Step Two — Have a safe, honest conversation with Don. Mal shouldn’t go into this meeting mad or looking to get angry. Because Mal hasn’t used the magic words of “my expectation is”, Mal shouldn’t be angry with Don.
A great way to defuse the situation is to clearly state: “I’ve done a poor job of communicating my expectations, and that is my fault as your manager.” First off, it’s true. Second off, it can dismiss the issue of blame and focus on solving the problem at hand, which is much easier to swallow for Don.
Step Three — Clearly state your expectations using the phrase “My expectation is …” Once again, my rule is if that phrase hasn’t left my lips, I can only blame myself if my expectations are not being met.
Step Four — Discuss with your team member specific examples of those expectations not being met, and why they are important. After stating Mal’s expectations, he should give specific examples of where his expectations were not met and why they are important.
“As a team, hitting our deadlines is very important. There are a lot of other teams depending on our project, and if it looks like things are going to take longer than expected we need to know as soon as possible. Our team is reliant on you being able to meet our deadlines.”
As Mal and Don discuss examples, Mal realizes that many times Don is finding other critical bugs that do need to be fixed, and other team members weren’t aware of it. So Mal comes up with another expectation: “Okay, so my expectation is if you find a bug that isn’t involved with the task you’re working on, you let me and the product owner know. We can then put it into the bug tracker and prioritize it appropriately. But that way you can still finish the task you were working on since other teams are depending on those features.”
Step Five — Ask if your expectations are realistic and if so do they think they can meet them? Sometimes as managers we don’t have realistic expectations. This is a great opportunity for Don to clarify things and get on the same page with Mal. This also gives Don some ownership in this expectations.
Step Six — Review your expectations. Mal should go over each expectation quickly summarizing it, and making sure Don is on board with it.
“So my expectations are first: that tasks get done in a timely fashion. If you have any questions on how long something should take, you’ll ask me. Second, if something looks like it will take longer than expected, you’ll let me know right away. Third, if you discover a bug not related to the task you are working on, you will let me and the product owner know so we can discuss priority and how to fix it. Does that sound like a plan?”
Step Seven — Follow up on your expectations. Now that you’ve clearly talked about your expectations, you can follow up on them. Hopefully, they are all met without any issue. If so, let that person know you’ve noticed and you sincerely appreciate it.
If there is a scenario where not all of your expectations have been met, the groundwork has been laid so you can follow up effectively and efficiently. In another private setting you can talk about any specific examples of the expectation not being met:
“Last week we talked about this task taking two days and it’s now been over a week. I understand that things can take longer than expected, but my expectation is that you communicate to me it is taking longer beforehand and not several days later. Let’s talk about what happened with this task, and how we can avoid these issues in the future.”
Conclusion
This is my first lesson on management I give to any new team lead or manager. It may seem simple, but I’ve found it is the root of the majority of management problems I face. Once I realized the trick of “My expectation is …” I improved as a manager (and I still have a long way to go).
Finally, the good news is that almost every single employee I’ve had wanted to be a good employee. They want to be effective and do a good job. I would say about 90% of the time when I’m upset with an employee, ultimately I realize I had an implicit expectation I hadn’t communicated yet. So while slightly uncomfortable, setting those expectations to solve so many problems. Be a good manager: clearly communicate your expectations.
— Carmony
Justin Carmony 