Skip to main content

Deals You Can't Miss

1 Year Subscription

Bad Boss Vs Good Karma : Page 1

There are things that early successes give you (the most important of it would be immense confidence in what you think is your secret to your success) and there are priceless lessons that early failures instills in you (the most important of it would be surprising benefits of virtues that you may or may not have embraced).

This is a true story.. an account of my story in one of the fantastic organizations that I had the opportunity to be a part of in my early carrier days. 

Very early on, I shouldered multiple small brown-field projects and was responsible for the quality of the software delivery and customer happiness. Back then, we used to develop software and generate artifacts for deployment to be handed over to the Ops-team managed by another vendor company in the US, for the target deployment environments were all there. This style of multi-vendor accountability can still be seen practiced by many companies even today. 

The early success that I'm talking about is the opportunity to lead multiple small projects/teams from the front. I was so relieved by it because it gave more visibility of my presence to the top management then. But but I also had a big challenge to overcome, it was my boss who stood between me and everything I did and wanted to do. He became more and more desperate to "align me to his whims and fancies", as I was cheered by my customers. Things can't be more unfortunate, a thing you would understand only if you were to have been in that kind of a situation. My boss desperately wanted to overthrow the vendor company and "snatch away those jobs" as he used to put it out. I hated every bit of it, because the intention was so damn wrong. If you win gigs by merit and good relationship, then that win is long-standing; otherwise it is just dirty. Had he dreamed of doing things better than the competitors/partners and had conversations in that direction things could have been very different. Our values were fundamentally different and in my opinion he was toxic to otherwise great environment that I have been working in.

As the ritual goes, I had once submitted an artifact to be deployed in QA environment along with the ticket I raised. The ops-engineer, by sheer accident had deleted it with the SLA for deployment nearing its expiry. This is a big thing in corporate world and it affects his "performance review". An occasion like this is what my boss was craving to paint bad about this vendor. Thankfully, I had hold good relationship with those I'm working with. This guy pinged me while I was about to leave office (I used to be that late worker who mostly lived in the office working and learning). When this guy pinged me, first thing I told him was to comfort him that this is no big deal and that I would happily extend my services to save him. He seemed to have been going through some bad time in his personal life and been making a few mistakes like this. When I re-generated an artifact and delivered it to him, he was so relieved and thankful. We became partners that respected each other.

In months down the line my relationship with my boss turned sour and he was looking for that single mistake I make so that he could escalate it big and paint me really bad. Just as he had desired, I had botched up, by submitting a wrong artifact to be deployed to production in the ticket that I had raised. Technically, I had to cancel the ticket and raise a new one, which would slip the delivery date. This time round I reached out to this guy who I helped earlier in the vendor team. As Good Karma would have it, even though this ticket was not assigned to him, he ensured to fix it all from his end for me. I escaped a potential escalation from my boss back then and lived in peace that I built a great relationship that I can rely on.

Helping others isn't a big deal of thing for me (and so it should be for you). I take no pride in it, rather it gives me a sense of relief that makes me so much lighter (Try it and you too will experience this). When I failed and my good karma paid for it, it was absolute bliss to experience. Luckily, throughout my life there has been many a times that Good Karma did pay back. 

Do not underestimate the value of goodness you can deliver. Just do it!

Also, in hind sight, even having a bad boss was good thing, because I wanted to get away from him and explore better world. And I indeed did it. From that world of manually doing things in a toxic environment to embracing the world of agility with automation via CI/CD, I came a long way in looking out for better ways to do things!

Remember this quote below to pep-up and work with your stakeholder or a partner in your execution, when he/she botches up:

“Forgetting your mistakes is a terrible error if you are trying to improve your cognition… Why not celebrate stupidities!” — Charlie Munger

We all will have bad bosses, experience bad times in personal and/or professional lives. You got to face it even if you have to leave it. But come what may, see if you can help others, if it doesn't cost you much.

My Popular Posts

Ten Commandments of Egoless Programming

We are nothing but the values we carry. All through my life thus far, I tried to influence people around me with the virtues I value. Thanks to some good reading habits I had inculcated, and the fortune of being in good community of peers and mentors alike, I managed to have read some real good books. This post is about the 10 commands of egoless programming in Weinberg's book. I shall explain the commandments based on my experience here. So very many decades ago, Gerald M. Weinberg authored  The Psychology of Computer Programming . In it, he listed The Ten Commandments of  Egoless Programming , which remains relevant even today for us as not just programmers but as team-members. Weinberg is regarded as a pioneer in taking a people-centric approach to computing, and his work endures as a good guide to intelligence, skill, teamwork, and problem-solving power of a developer. When they appear to inspire and instruct, we find that they can apply to just about every business area, and e

Should I buy refurbished laptop from Amazon?

This post is based on my experience with and guess it to be true on all other platforms as well. At least you can check out and verify for these pointers before you make that decision to buy renewed/refurbished laptop on Amazon with your hard earned money. I see this question propping up in several forums and on many different occasions. In the recent past, I had my 5 year old dell laptop that gave up because its motherboard failed. One of the options that I had in my mind was to re-use the HDD and the 16GB DDR4 RAM of that old laptop in the one that I purchase next as secondary.  I had come to a conclusion that it is not worth buying a refurbished/renewed laptop at all. Why? For the following reasons, most of which I see as BIG #RedFlags: You got to remember that Amazon provides a platform for 3rd party sellers to sell their products as well. So in your search for refurbished laptops you wouldn’t want to choose some random 3rd party seller who Amazon doesn’t endorse. You cou

Multi-tenant Architectures

  Multi-tenancy Application Deployment Architecture could be modeled in 4 broad ways: Separate Apps & Separate Databases Shared Apps & Shared Databases Separate Apps & Shared Databases Shared Apps & Separate Databases There is no right or wrong here. It's about choice and consequence that you should consider taking into your business context and constraints. In this post I intend to jot down a some key points to keep in mind for each of these multi-tenant architecture. These are more of quick notes for my quick reference, a cheat-sheet of sorts when I have to make choices. And I guess this can come handy to you too in your wise decision making. Separate Apps & Separate Databases Easiest to implement from development and deployment stand-point. Just automate the deployment infrastructure for every tenant for quick set-up. Most expensive of all the models from infrastructure cost stand-point. Relatively longer deployment t