In my earlier posts I gently nudged young and budding developers to be there and not evacuate the pond when boulders are getting thrown at it. Feel the ripples, deal with the pressure, get your work done and while you are at it, also try and have some fun.
Of the many reasons why staying the pond when boulders are being thrown at it, one of the most important reasons can be explained in one word: cover-fire. Cover-fire is what I do when my manager hints at the fact that I am running slow on a project. Cover-fire is when I know the fact that Jack is not in the flow and isn't shipping but I decide to keep my gob-shut and not explicitly mention that during the discussion with my manager.
As members of the same pack we tend to give cover fire to others in the pack. The cover fire is based on trust that has been developed over time. It is also a personal thing.
You know Jack has a problem on his family front, you also know that he is trying his level best, he is showing up, he is putting in his hundred percent. All he needs is some time and that some time is not going to kill the project. You decide to pull your management gun out and give Jack some cover-fire.
There are times when you know that Jane is going to propose an architectural approach that will rescue your project, but then she is not very articulate at describing the approach to the folks sitting on the other side of the table. You decide to drop in at the meeting, take sides and explain the long-term-ROI of the architectural solution Jane is proposing. The 'managementese' that most people in that meeting-room understand really well. More cover fire.
Then there are times when you receive cover fires. Remember that vacation that you took or that holiday that you took to get your personal-pet-project wrapped up. That is when someone from your team chimes in and works on getting the next sprint shipped exactly on the same day as you had planned even if you are not around. No-one misses you. You come back from the vacation only to find that everything is exactly as you would have wanted it.
That is your team giving you exactly the kind of cover fire you need and keeping you out of trouble.
Cover fires are built on mutual trust, respect and an unspoken pact that if you are not performing to the best of your abilities, you will revive, recover and come back soon. When people you work with understand this about your work ethics, you are what I call, cover-fire-worthy.
You live up to that trust and respect by honoring that pact. By getting back in the flow and helping the team move forward.
Of the many situations where you lose your cover-fire-worthiness one is when you break the trust and respect that was causing your fellow programmers to give you the cover fire in the first place. Take cover fires for granted and be rest assured that you will find yourself smack in the middle of the battle field all alone.
You also typically tend to get lesser cover fire when you are constantly not around when your fellow programmers need you. I have seen this theme over a dozen times in my life. I have observed it rather closely and I think I understand how a team of seriously kick ass developers works in times of crisis. Take a team of kick-ass developers when every team member is closely knit with another and put them in a crisis situation.
Chances are that you will see very little finger pointing. Problems will be discussed, ideas will be brainstormed but no specific names of developers causing delays will come out during management meetings and status calls. You will never hear Jane saying for instance, that the project is late because Jack is not doing his work as quickly as the team expected him to do it. In fact, you might actually see Jane defending Jack.
Now, get Jack to go to a few parties with friends when the entire team is struggling and getting the sprint out or keeping the sky from falling. Then get him to turn his cell phone off. Do this a few times over and what you have done is shattered Jack's cover fire worthiness to pieces. Now do a management meeting and chances are that you will hear a couple of developers hinting that Jack is causing the sprint to get delayed.
What is going on here is simple. The team is booting Jack out and refusing to give any him cover fire primarily because they know that Jack is no longer cover fire worthy.
If you are a young and budding engineer doing your job, kicking some serious ass with your programming skills and moving up the corporate ladder of promotion watch your cover fire worthiness very carefully because everyone needs cover fire once in a while and if you have lost your cover fire worthiness, you are going to have some seriously difficult battles up ahead.
Cover fires are good and if you see someone in your team who genuinely needs them, go ahead and give them some. On the other hand, if you notice someone losing his cover fire worthiness or taking your cover fires for granted, look at him in the eye and tell him he is losing the trust that made him a kick ass programmer in the first place. This is one issue you are way better of confronting rather than avoiding. Go ahead, talk about it, openly and candidly.
I wish you good luck.
Comments are closed.