You are brought into a project that is sort of a dream project. It may be a contract, it might be a new job, or it might be to do particular work at your existing company that you have lobbied to do for years. This is finally the moment. The flood gates open. Let’s make it a concrete example, with the boss saying something like this:
“We all know that project Bliz is a mess we’ve been patching for years. Each patch makes it a little worse. The code is spaghetti, the architecture is a big ball of mud. I’ve finally got some time for someone to fix it, but they’ve got to have significant skills, because these changes can’t add new bugs and we have no unit tests. So it’s you. You’ve got (six weeks to six months) to fix the code.”
You go on to have a conversation about what might be possible in that time. Because of your special skill, because you lobbied for this, the boss is pretty open to your timeline and ideas — just as long as you stick to deadline. At the very end, he adds “Oh, one more thing. We want to have confidence to make changes and roll out the entire package. So make sure this project includes a smoke test that covers the high level transactions.”
The project proceeds. Again, because it is your baby, the boss doesn’t worry too much about managing it hands-on, just asking for a brief presentation and demo on deadline day. The day before the presentation, you finish up the slides and send them off. At 4:55PM, he sends you a quick meeting request, and he pops onto zoom. He says “This all looks fine, but what about the smoke test suite?” You explain that you didn’t have time to get to that.
“I’m confused”, says the big boss. “Let me get this straight. I asked you to do one thing. One thing … and you didn’t have time to do it? Now you are going to present this work to the next two laters of management without the one thing I promised them in order to get the project funded? What have you been doing for six months?”
Don’t let this be you
Here’s a very simple career tip. Anytime a leader adds something at the end that seems to be unrelated to the project, ask “That seems important to you. Should I do that first?” From there, clarify if the work is more important — if it would be better to get that done than the “main” task. This is especially important of vague, amorphous efforts like “clean up the code”, “improve the architecture”, and tasks that will never end, like “provide ongoing support.” Then follow up in an email that you heard them today, that (thingOne) is #1 priority, should take about (timeline) and that (thingTwo) is priority two. If they say no, it is a “nice to have”, then follow up by email, sayin you heard them, and you will try to include thingOne as time allows, but you recognize it as second-tier request to be worked on in discretionary time. That is, you might not get to ThiingTwo before deadline, and that is okay. Discretionary time is time waiting for builds, for answers and permissions when blocked, and so on.
The purpose of the question and email is not Cover Your Tail (CYT), but instead to make the priorities clear.
I say this because as a leader, I’ve recently heard a fair bit of “Oh we didn’t get to that”, when that was the one thing I tangibly asked for.
There is a difference between “make sure you get it done before the deadline” and “This unrelated thing is a nice to have.” Sometimes, we hear the latter. Sometimes, the person asking means the former but says the latter. Dig for clarity early. Of course, it is always possible the person is trying to get something for nothing “moving the goal posts”, or has a terrible memory.
That is what the email is for.