Stop Being a Yes Man
Even your boss can make mistakes
Congratulations! You just got the job you wanted. After a long and tiresome process that included multiple interviews and tests in which you tried your best to prove you are worthy, you can finally relax and do your job, right?
Well, if you suffer from imposter syndrome like me (and most software engineers) you have only begun proving yourself. Soon enough you’ll be assigned to your very first task, and at that moment the clock begins to tick.
Your new key metric is MTTP — Mean Time To Please, which is the average time between receiving a task to the moment your manager thinks to herself/himself “What a great job s/he has done. Picking her/him was a smart decision. I am glad s/he didn’t turn out to be a fraud.”
Finally, the task is done; the code is in production, all the dashboards seem promising, and there are no signs of complaints from customers. Can you rest on your laurels? Of course not — the second task was already assigned to you and you might not get as lucky as last time, so you need to get to work as soon as possible so you won’t screw it up and everyone will inevitably find out that you — are just an imposter.
Don’t get sucked into the endless loop of compliance! I can’t stress enough how important it is to resist your inner need to please. You might think that obedience makes you a good and loyal employee but in fact, in some cases, it is in the best interests of both you and your employer to stop and think first.
Anyone can (well, at least try) to complete a mission, but identifying future hurdles in advance requires skills (and dare I say experience?) and can prevent time waste. Even if you occasionally fumble, your doubts will be appreciated and help you gain respect and recognition. In the following paragraphs, I’ll describe some of those cases in which I urge you to speak your mind before getting to work.
When the task is not well-defined
Every task you are given should be properly and fully specified. If there is any room for doubt, ask for clarification before starting to work on it. Ambiguity is your enemy — and as a software engineer, you should try not to guess the intentions of others. An Implementation of the wrong functionality can get into production (as the testers of the code might not know the expected behavior either) and can result in the disappointment of your clients or product team.
Whenever I get a task I always ask myself: Do I know what to do? Do I know how to handle each and every possible edge case? Can this task be interpreted differently? If an assignment is important enough for you to work on — it is also important enough to be put into words that describe it clearly without leaving any chance of misunderstanding, preferably in a project management tool like Jira, Trello or Monday.
When you lack the resources to complete it
Always make sure you are capable of handling the task you are given. If you don’t have enough time — make sure the task isn’t urgent. If you lack technical knowledge — find out how to acquire that knowledge, and if you need to collaborate with a colleague — make sure you will get the support you need.
There is no shame in saying “I will need to consult our software architecture before making a decision about the design of this new system”, or “I will need some time to master the tools required for this task, as I haven’t used them before”. It is preferable to plan and use the resources needed ahead instead of desperately seeking them later on, for example, when you need to firefight the inadequate mess you deployed into production.
One of my best cautionary tales for such a case happened when I started a task that required the implementation of a supportive feature by another team in the company. I naively assumed the other team was aware of my task so I only reached out to them once my part was fully implemented. It turned out that they were not looped in on this task at all, and they had a lot of reservations about it. I ended up making major changes to resolve their objections, and on top of that, I also got a (rightful) earful about the fact they were left out of the planning phase of this project.
When the task is not really needed
Every human makes mistakes. Even managers. Upon being introduced to a new task it is crucial to understand the need for it. Who is going to use this feature and how? Is it part of a wider plan or a roadmap? Trust me — you don’t want to find yourself writing tons of code and making a simple system a whole lot more complicated just to support a new feature no one will ever use. You will frustratingly watch it stay untouched and have no admirers in the world except you and the branch predictor.
I had such a feature once. We had a system that used a weight function that aggregated several parameters with fixed coefficients, and I was asked to enable A/B testing of the coefficients. I needed to rewrite several parts of our system to support multiple weights per parameter and made sure to calculate different values for each variant of the test.
When my code was done, I waited to be asked about activating it, but no one asked. I tried to snoop around and apparently, all the variants were occupied by other A\B tests. I guess this test wasn’t important enough as they moved on and tested other things on released variants, and I forgot about this task. Luckily I stuck around long enough, and 17 months after it was deployed I was asked for the first time about using it. Good thing I remembered how.
When the task is not feasible
“Unrealistic expectations always lead to disappointment”
— Dr. Paul David Tripp
Understanding the capabilities of a system might be difficult, especially for those less familiar with its fine details. Unfortunately, some of those people might ideate tasks under your domain, and you might come across a task with unrealistic requirements, like doing heavy actions in performance-sensitive parts of your system or solving P=NP.
My recommendation for such cases is to suggest an alternative solution, if you have one in mind: “I can’t do such calculation in our online serving flow, but it can be done in an offline flow”, or “I can do this task but it will require additional ~X% more CPU than we currently have \ it will damage our latency by ~y%”.
Even if you are not explicitly asked to define and evaluate tradeoffs, it is something that can be implicitly expected from a software engineer. When you share all your relevant knowledge and insights, it is possible to make a wiser decision about whether you should proceed with that course or not. It is imperative to talk about those things before writing any code.
When the task is not given by your direct manager
In most cases, getting tasks from multiple sources leads to a mess. One of the roles of your manager is to prioritize your tasks, and he\she can’t do that without knowing them.
I had a grandboss (2nd-level manager) that made me write the book on getting tasks by hierarchy. Whenever he had an idea for a task that matched my skill set (and he was very creative), he would ask me to do it. At first, I bit the bullet and tried to juggle it with the rest of my tasks, but having two people pressuring me to complete the task they gave me at the same time was just too much to handle.
After a few times, I reached out to him (with my gentle politeness and sincerity that I am sure you’ve surely sensed from my writing) and asked him to pass those tasks through my team leader. Having a single person prioritizing and tracking my work simplified my daily reporting routine and greatly improved my on-time production.
When the task does not align with your moral compass or the law
Thankfully, I haven’t had such a task, but I guess it could also happen. If you have ethical or legal concerns about your task, for example: If you are asked to write code that violations data privacy or if you are asked to implement a biased algorithm that discriminates based on ethnicity, gender, or religion, or if you feel a task can be used for harmful purposes like misleading clients — refuse to take part in it without consulting the proper stakeholder like the company’s legal department or data protection officer.
There are many good reasons to question or even reject a given task. However, it is very important to do so gently and respectfully. Raise your concerns calmly and with a reasoned explanation, be open for a dialog with the other side that might not agree with you, and if needed — find a way to compromise for the middle ground. There aren’t many cases that are worth burning bridges for, and I hope you will never encounter one.
