Posted On: Friday, 06 February 2009 by Rajiv Popat

If your manager behaves like an angry tiger; chances are that he is putting up a mask; behind which, lives a timidly scared and insecure individual.

Scott Berkun describes this type of insecurity as one of the ten primary reasons why Project Managers And Development Leads become assholes. He explains why managers often act like assholes:

They are insecure in their role. The psychology of opposites goes a long way in understanding human nature. Overly aggressive people are often quite scared, and their aggression is a pre-emptive attack driven by fear: they attack first because they believe an attack from you is inevitable. Management makes many people nervous since it’s defined by having have less direct control, but more broad influence. A huge percentage of managers never get over this, and micromanage: a clear sign of insecurity and confusion over their role and yours.   

Insecurities manifest themselves in multiple forms but the most serious form I have witnessed till date is the fear of becoming redundant. Most managers who are not from development, programming backgrounds and are managing projects are walking, talking, breathing examples of this form of insecurity.

Even technical managers are not immune to this insecurity.

In fact, to be honest, chances of you having this insecurity exist, even if you are the best developer in your organization.

The act of having written all that code for that critical module in that critical project, for instance, gives us programmers, what can be called, a 'perceived' sense of security. We love the warm and fuzzy feeling of our 'organizations' needing us for a a very long time in the future as much as we hate and fear the feeling of not being needed.

If you are working with a team your first responsibility as a manager; is to lose this sense of insecurity.

Now, that's easier said than done.

As it turns out, this insecurity is not 'that ring' which you can just lose in the sink. The fundamental problem of transitioning to leadership role is that this insecurity, in most cases, has a tendency to multiply rather than getting reduced; especially as you move up the pecking order.

Michael Lopp, in his post, describes this tendency of managers getting sensations of insecurity, rather articulately. He explains:

This sensation will appear at the end of the day when you ask, “What did I build today?” The answer will be a troubling, “Nothing”. The days of fixing ten bugs before noon are gone. You’re no longer going to spend the bus ride home working on code; you’re going to be thinking hard about how to say something important to someone who doesn’t want to hear it. There will be drama. And there be those precious seconds when there is no one in your office wanting… something.   

It is this sensation of building 'nothing' day after day that makes most managers feel insecure and take their first steps on the path to prickdom. This fear of their team or their organization finding out how easily replaceable they are, is exactly what makes them forget their 'not to do' list and makes them do too much. Most managers jump from creating Gantt charts, to organizing meetings knowing deep down inside that none of these activities do not add any value what-so-ever and yet continuing to sound detail oriented and in charge; instead of just getting out of the way and letting their teams drive.

Having said that however, turns out, depending on what you do with this insecurity, which is usually supposed to get you started on your path to prickdom, matters. This same insecurity that gets you started on your path to prickdom, can help you become a kickass manager, if channeled in the right direction. Used correctly and generously this fear or insecurity can transform you and take you to the next level of genuine competency. It is like taking the devil along with the angel when you head out to war against prickdom.

Used wisely, what this insecurity allows you to do is 'scale up'.

Don't knit your brows.

I'm not asking you to 'scale up' like the VP of sales and marketing expects your development team to scale-up-and-do-more-with-less; that's not what I mean. I'm not talking Managementese here.

The fluff aside, scaling up is one thing that needs to be one of the primary things you focus on in your career profile.  Michael talks about the art of scaling up using a writing style that is not just fun to read, but rather motivating . He explains:

As a new manager, whenever the sky falls, you’ll become an engineer again. You’re going to fall back on the familiar because those are the tools you know and trust, but it’s time to trust someone else: your team.

If I could give you one word, a single, brief piece of management advice, the word would be “scale”. Your job as a manager is to scale the skills that got you the gig in the first place. You used to be the guy who did the impossible when it came to fixing bugs. Ok, now you’re the guy whose entire team does the impossible bug fixing.

It’s time to translate and to teach what you’re good at to those who you work with, and that starts by trusting them to do that which you previously only asked of yourself.

The benefits of defining and maintain this trust create a satisfying productivity feedback loop. By trusting your team, you get to scale, and scaling means you hopefully get to do more of what you love. The more you do, the more you build, the more experience you gather, the more lessons you learn. The more lessons you learn, the more you understand, and that means when more shows up you’ll have even greater opportunity to scale.   

Put simply, to me scaling up means that you try to make yourself completely replaceable. You work hard to make yourself a primary candidate who can be fired without any dependency or hassle; because his team knows what they have to do and can continue to do it; even if you are not around or decide to quit. It's like building self sustaining eco systems in fish tanks. Continuously.

I'm not talking about traditional succession planning here. I'm talking about enabling your team to do everything you are doing and encouraging them to do it better; even while you are around. Make them replace you so that you are no longer a critical part to the success of the project.

Yes, that makes you primary candidate for being fired; but if it actually does gets you fired; you didn't deserve your job anyway; or maybe your organization didn't deserve you; either ways; it is best for you to move on.

My first lessons at scaling up came in when a young and budding developer at a client office, working for them, approached me asked me if I could explain the security piece that I was leading. Here's how it happened; he was free, had nothing to do and wanted to contribute. I was way too busy and way too insecure to let go ownership. I politely dodged his question with a - sure-maybe-some-other-time-when-I-am-free answer. As a matter of fact, My being busy wasn't a problem; my being insecure, was.

I'm not sure why I did that, but the very next day, I randomly walked over to his cabin and I think I spent over five hours taking him through the entire module, showing him how to debug the module and running him through the entire implementation. Then I spent a couple of hours showing him where my code sucked and asked him to see if he can come up with better ideas. It was the very next day something creepy; almost Hollywood style, happened. I lost my insecurity - just like that ring aught to have been lost; and most importantly, it was fun. 

Three weeks later this young and budding developer of ours was leading the security module. I moved on to code-reviews; working on the nastiest performance fixes and challenges which were so insane I loved working on them.

Early on in my career, it was divine coincidence, that made me stumble upon my first experience of 'scaling up' by making myself completely replaceable and then working my ass off to take up an even bigger and better challenge. It was like a tame lion, tasting his first few drops of blood. The rest as they say is history. Today, one of my measures of success if I am supposed to be managing it is - how easily will the project continue to run if I were to quit for good without any replacements.

Once this level of temporary uselessness is achieved; I love flaunting it, talking about it rather shamelessly and finding something much more challenging to do.

May I suggest dear reader that you do some serious soul searching on if you have insecurities about your colleagues beating you in the race of getting to the top? If you even heard the mildest whispers of the word 'yes' while asking that question; may suggest you act now and start on your journey to overcome these insecurities. Multiple techniques exist:

  1. Pick what you learnt last week and conduct a knowledge sharing session. You insecurity of having no competitive edge will make you learn more in a desperate attempt to stay ahead in the stupid rat race; then conduct another session again after you've learnt something new. Keep doing this till you no longer feel insecure; and if possible continue doing it even after that; just for the fun of doing it
  2. Take the module you own; explain it to someone and then hand it over. Help the other person when needed; but don't code on it. You insecurity of having nothing to do and not being very needed in your organization will make you probe into other productive areas; then teach those to someone else and hand them over as well. Once you've manage you use and lose all your insecurity; continue doing it anyway.

Long story short; use your insecurity till you lose it. Learn the art of making yourself completely replaceable and dangerously close to getting fired each year; and then, if you still don't end up getting fired year after year, you'll know you're growing. I wish you good luck.

Comment Section

Comments are closed.