Hey, it’s Alvin!
Quick announcement: I started a YouTube channel, which you can visit by clicking here. My first video is based on Dive 2: Hope… Why you need it. How to make it. If you’re an audio or visual learner, you’ll enjoy this new experience. And if you enjoy this newsletter, consider supporting my channel by subscribing and sharing it with your friends. I really appreciate it. Thank you!
Now, on with today’s dive…
When I started my career as a software developer, I had a mentor named Felix. I saw him as a knowledgeable, experienced senior developer, and would often consult him when I was stuck on a problem. We also got along well. I often had questions I could answer by searching the internet, but I asked him just so I had an excuse to chat and joke with him.
Felix wasn’t just my mentor; he was also my project team’s technical leader. I was a backend developer focused on developing server to server communications. It was pretty straightforward. He had a much larger task of developing an entire restaurant management mobile app from scratch alongside an intermediate developer and a few interns. This was back when only the trendiest restaurants began introducing tablets for their staff to use.
One day, I saw an email from our boss asking when the mobile app would be done. Felix replied it would take a couple of months. I don’t remember the exact number; it’s too long ago. Our boss replied he wanted to know why so much time was needed. So Felix sent him a breakdown of all the tasks that needed to be done to flesh out the details of the timeline.
There was a bit more back-and-forth in the email thread. The boss was trying to cut down on the time needed to finish the mobile app. While Felix pushed back, reasoning that the features had to be done in certain ways to ensure they worked properly, and that the overall software product was of good quality.
Tired of the email thread, the boss called Felix into his office.
I don’t know what happened behind that closed door. But, after the “discussion,” the boss sent one final email message that the mobile app was to be done in a few weeks. And if anyone had a problem with that, then they should go see him in his office. Anyone who could read between the lines knew what that meant.
The discussion was over.
The mobile app developers worked evenings and weekends to produce something functional by the deadline. It’s hard to tell whether the boss was happy with the final product. He almost never praised or gave positive feedback on anything his developers made.
What matters is not what Felix achieved or did not achieve from his push back.
What matters is that he made a concerted effort to push back on what we thought were unreasonable demands. Because it showed that he had our backs. It showed he had, at least some, integrity to fight for what’s right. And I don’t know about you, but when someone fights for me, I don’t just trust them more; I want to fight for them, too.
Effort matters. People can tell if you’re pretending to fight for them or if you’re actually fighting for them. It helps to show your support in the open rather than behind closed doors. Our team could see Felix’s efforts in plain sight of the email thread. And we all knew our boss was a heavy-handed fellow who threatened to cancel entire projects before. So, we knew pushing back on anything was not easy.
Of course, pushing back on everything makes you petty. So managers may take you less seriously if you do it too often. As my friend Sam Cho says, “Not every disagreement needs to become a battle and not every battle needs to be fought. Retreating allows you [to] fight another day for when it really matters.” Sam does a much better job of explaining this than I can in Issue #026 of The Forcing Function.
Felix also had a certain “fuck you attitude.” He didn’t go looking for fights. It’s just that he didn’t take shit from others and wasn’t concerned with the consequences of pushing back. He always seemed confident he could find another job if he lost the one he had.
His “fuck you attitude” inspired me.
Many years later, I found myself on another software development team. Already, I wasn’t completely satisfied with how the team worked day-to-day. And one day, I was asked by the team lead to write a script for a database trigger. The trigger was to generate an error if someone tried to add a record to one table without a related record in another table.
I thought to myself, “ok, this is dumb.” It was tiring to see half-assed solutions to problems. So, I reached out to the team lead and asked him, “why can’t we just use a foreign key? A foreign key would do the exact same thing, but it’s way simpler, and easier to add and use.”
He explained he was worried adding a foreign key would accidentally delete some of our precious data. I said, “no problem. I’ll write a one time script to update the data so that doesn’t happen. We’re going to need the foreign key eventually, anyway, because it’s the proper solution to this problem. And the sooner we do it, the less data we need to update.”
You know what? He agreed!
Experiences like these left me with a few other life lessons:
Only push back when you have a sound reason to do so because people will have their own reasons to push back on your ideas, and they need a reason to change their own behaviours. So, your reasoning gives you strength to defend your position and push back.
Effective push back requires listening to understand the other person’s underlying needs, so you can address them. They’re only pushing back on you because they have unresolved concerns. In fact, the point of voicing your concerns is just to get the conversation started. The main goal of pushing back is to address the other person’s concerns.
Push back is about removing their roadblocks, not yours.
If you’re successful in pushing back, you’ll gain confidence like you would from any other win. Winning builds confidence.
If you’re unsuccessful in pushing back, you will have learned something if you put in the effort to understand the other person’s point of view. Because you have a better understanding of the other person’s concerns, you’re now in a better position to remove their roadblocks. This gives you the reasoning (and therefore, confidence) you need to try to push back again. So, even if you’re unsuccessful in pushing back at first, you can still gain confidence.
I hope you enjoyed this dive Below the Surface of why and how good leaders push back on unreasonable asks. Reply to email@example.com if you have questions or comments. Have you ever had to push back on unreasonable demands? Let me know. I’d love to hear from you.
Thank you for reading. Push back when you need to. And I’ll see you in the next one.
Thanks for the shout out!
The analogy I found very useful is
Don’t be a waiter. Be a doctor.
In software dev, we are paid to solve problems especially the painful ones
Not churn out features like a factory
So don’t be like a waiter taking orders. I’ve made this mistake before.
Be a doctor who needs to ask questions and learn to listen on between the lines in order to diagnose the root cause that best solved the problem.
Sometimes you have a complex situation and you need to disagree with the patient in the best course of treatment
So you have to push back with wisdom (because you diagnosed the root cause) , compassion (there’s a reason why you’re the medical expert and not them so be kind with the patient’s ignorance) and no amount of skill (no two patients are the same even when they have exact same diagnosis so need to adjust the push back accordingly)
I find this analogy to be compressed wisdom
Having said that I have not found a good one that covers the confidence Felix has shown in appearing not to fear losing his job