When you were a child, your grandmother told you, “You’re special, you possess a unique charm; you’re like a hero!”
First, you laughed…then you started liking it and eventually started believing that you’re a hero… someone very special!
Then, after years of education, you became a software professional and got a good job with one of the top IT organization, but still, in the back of your mind, you have treasured the old image, “I’m a hero!”
That’s where the problem rests for many software teams.
Since you consider yourself a hero, you inevitably strive to reinvent everything. Right from what other team members should have done to organizational processes or what the customer should have expected instead.
Your coarse argument would be, “No one in this organization can work like me. If I were not in that team, that big problem could have never been solved.” Or “People out here do not know even 10% of what I know and I don’t think they will be able to perform the task so effectively when I am not in the team.”
Instead of being open and learning from past mistakes of colleagues or everything else around, you insist on doing everything on your own; at the cost of the client or the organization.
You spend most of your time in beautifying your own code, debugging your less experienced colleague’s code or re-creating architecture of the half-developed business application.
You need to understand that you’re not a hero. At least not at the workplace. If you become one, it is not going to give you benefits after a certain point. Reserve that narcism for your visit to your grandmother’s house.
Be less heroic. Be less special. Be more agile. Focus more on how your team can add value. Ship early; ship often rather than investing your time in less necessary artifacts in order to build a product or a service that works. Inspect and adapt. Remember, none of us is as powerful as all of us.
When the performance appraisal happens, and one colleague is promoted, many of his co-workers don’t feel good. They compare themselves with him and conclude that their boss favors only who flatters her. Always, that may not be the case. For example, read the below story called Navigate Without a Map.
Navigate Without A Map
Background Peter and Scott – both joined the company on the same day as Analyst Programmers. Both were coming from different background but had two qualities in common. Both were hard-working and committed to their work.
Promotion of Peter After a couple of years Peter was promoted as a Lead Programmer while Scott did not get the promotion. Scott got upset with this, drafted the resignation letter and went to Stella, his Department Manager. He complained that Stella does not value hardworking staff and promotes only who blandishes her.
The difference Stella knew that Scott also worked hard for past two years but she had a point to address and make Scott realize the difference between him and Peter.
So, she discussed a scenario with Scott, “While working as a dedicated developer with an offshore client, if you reach a limbo stage when there is no work for couple of weeks. How’d you proceed?”
“I’d call the client and ask for the work”, was Scott’s reply.
Stella explained further, “The client responded that he needs to send you some task specifications but he would be able to send it only after two weeks when he’ll return back from vacation. So the limbo stage continues. What should be the next step?”
Scott said, “Well, since I have no work, I’ll work on my pet project or do something else. May be I will also take some leaves. Given it is a Dedicated Developer Contract, client is going to pay for the two weeks anyways so he can’t blame it on me or the organization.”
“Well,” said Stella. “Let’s discuss the same scenario with Peter and ask what would he do.”
Peter responded, “Well, first of all I won’t come in the limbo stage because I keep communicating with the client very frequently and always make him aware about the work status. But still if that stage comes and I do not have anything on my platter, here’s what I’d do:”
Optimize the code for performance – I’ll utilize the knowledge I’ve gathered in Application Performance Improvement classes I attended in the last weekend of April.
Recheck the code comments and take it to the next level. I understand that there is no comparison between well-commented code and just the code.
I’ll do some research and learn more about my client’s business. I’ll also prepare a document which will outline the knowledge I’ve gathered by performing the research. I’ll share that with the client also.
I’ve some high level idea about what changes he wants to make in the software I’m working on. So I’ll make some draft user interface and modified architecture diagram with added application scalability.
I’ll record such additional activities and submit a report to the client such that he can know how I’ve utilized my time for which he is paying.
I will do…
“OK, Great! This information is sufficient for what I was looking for. You may go and continue your work, Peter.” interrupted Stella.
The realization Scott realized the point which Stella wanted him to understand. He understood that Peter has an edge over him. He observed that:
Peter had absolute clarity about where to go and how to proceed even when no path/direction was given.
Peter had invested his time to learn different technology verticals which are even indirectly related to his core strength by investing extra time over the weekends.
Peter is a servant leader. He’s willing to learn his client’s language (business) so that he can serve his well.
Peter does not need a map to navigate. Instead, he is willing to move ahead when there’s no map. He will try hard to improvise application’s architecture and would work on making it still better.
Peter utilizes the information in a way it becomes meaningful to the client and the organization. Most important is that he keeps all the important information in the written form.
“I want to take back my resignation,” said Peter. “I’ll learn from Peter and try to be an equal or better version of him.”
Only hard work and commitment are not sufficient. You need to develop an ability to navigate without a map (Yes, wordings are taken from Linchpin by Seth Godin – a good read, btw.)
We’re in a different age where rulebooks are not matching pace with the changing demands of the workplace so start thinking beyond the rulebooks, take personal risks and excel at what you’re doing. Remember, observation power is a big differentiator. And, excellent use of observed information may take you a long way.
Maybe that’s the reason we are given with two ears and two eyes but only one mouth. So speak less, observe more. Maintain a mental database of observed information, index it often and use it to navigate when no map is available. 😉