If you study some of the awesome kick-ass managers you've worked with in the past or are currently working with, chances are that you'll begin to realize that all kickass project managers and the best team members in your team are much like the 'Men In Black'.

Seriously.

Consider this conversation between agent Jay and agent Kay from the 'Men in Black' for instance:

Kay: We do not discharge our weapons in view of the public! Jay: Man, we ain't got time for this cover-up bullshit! I don't know whether or not you've forgotten, but there's an Arquillian Battle Cruiser that's about to... Kay: There's always an Arquillian Battle Cruiser, or a Corillian Death Ray, or an intergalactic plague that is about to wipe out all life on this miserable little planet, and the only way these people can get on with their happy lives is that they Do... Not... Know about it!

As funny as it might sound, the conversation to a large extent sums up what most kick-ass managers do. Honestly, it does. However there is one subtle way in which kickass managers differ from the 'Men In Black'. Unlike Jay and Kay, most kick-ass managers I've seen in action or worked with aren't even aware of the fact that they are saving worlds and changing cultures. They do so, silently and instinctively.

Tom Demarco and Timothy Lister explain the point I'm trying to make here, much more articulately than I will ever be able to explain it, in their classic book, Peopleware: Productive Projects and Teams. They explain this using the classic example of the Spaghetti Dinner:

Picture yourself a technical worker who's just been assigned to a new project. You know the manager and most of the other project personnel by name, but that's about it. Your first day on the new project is next Monday. On Wednesday before that Monday, you get a call from your boss-to-be. She's having a get-together, she says, for people on the new project. Is there any chance you could come by her place on Thursday evening for dinner with the rest of the team? You're free and want to meet the new group, so you accept. When you arrive, the whole group is sitting around the living room drinking beer and telling war stories. You join in and tell a few of your own. The client liaison, who has also been invited, does a bit about his department head. Everybody has another beer. You begin to wonder about food. There is no smell of anything cooking and no sign of anyone working in the kitchen. Finally your boss-to-be admits that she hasn't had time to make dinner, and suggests that the whole crew walk over to a nearby supermarket and assemble the makings of a meal. "I guess we must be capable of putting a spaghetti dinner together." Team Effects Beginning to Happen. Off you go. In the supermarket, you amble as a group through the aisles. Nobody takes charge. Your boss seems to have anything on her mind but dinner. She chats and laughs and offers up a story about the IRS. In spite of a general lack of direction, some things do get thrown into the cart. One fellow has already gotten the salad pretty well taken care of. There is some talk of making a clam sauce, and when nobody's opposed, two of your new mates begin to talk out the details. You decide to make your patented garlic bread. Someone else picks out a bottle of Chianti. Finally there is a consensus that enough stuff is in the cart for dinner.

If you weren't able to make out what just happened in the little story above or where I was trying to go with this post 'Peopleware: Productive Projects and Teams' also provides a very insightful explanation of what just happened in the story:

So far, nobody has billed a single day of effort to the project, but you've just had your first success as a group. Success breeds success, and productive harmony breeds more productive harmony. Your chances of jelling into a meaningful team are enhanced by your very first experience together. Presented this way, the spaghetti dinner may seem like a contrivance on the manager's part. But it probably wasn't and wouldn't have seemed like it had you been there. If you had asked the manager in question what she had in mind for the evening, she would have probably replied in total sincerity, "Dinner." A natural manager has got a subconscious feel for what's good for the team. This feel may govern decisions throughout the project. The entire experience is organized for small, easy joint successes. You have to look twice to see the manager's hand in any of this, it just seems to be happening.

The act of implicitly, innocently and unknowingly creating excellent work environments and cultures is a well known ability in kickass managers and true leaders. Michael Lopp describes this same act of unknown, silent, subtle and true leadership; in his post on the culture chart; where he talks about a core group of men who defined the engineering culture at Netscape by playing the game of bridge right in the middle of the cafeteria every Wednesday. He explains:

If you looked up the four core bridge players on the org chart, you'd learn a bit. One engineering manager, another guy from some oddly named platform team, another guy who had a manager title, but no direct reports, and the last guy who looked like a program manager. My org chart assessment: Meh. What I learned months later was that the folks sitting at that regular bridge game not only defined much of what became the Netscape browser, they also continued to define the engineering culture or what I think of as a culture chart. Unlike the org chart, you're not going to find the culture chart written down anywhere. It doesn't exist.

Irrespective of how big or small organization that you work for, run or own is, chances are really high that the culture chart has more influence on your organization than any other single factor. Michael, in his post describes elaborately how the culture definers innocently shape a positive environment around them and how you can detect the culture chart within the organization:

To deduce the culture of a company, all you have to do is listen. Culture is an undercurrent of ideas that ties a group of people together. In order for it to exist, it must move from one individual to the next. This is done via the retelling of stories. “Max was this nobody performance nerd and three weeks before we were supposed to ship, he walked into the CEO's office with a single piece of paper with a single graph. He dropped the graph on the table, sat down, and said, 'No way we ship in three weeks. Six months. Maybe.' The CEO ignored the paper, 'We lose three million dollars if we don't.' Max stood up, pointed at the chart, and said, 'We lose ten if we do. We must not ship crap.” Whether this story is true or not is irrelevant. The story about how Max saved the company ten million dollars by telling the CEO “No” is retold daily. In hallways. At the bar over beers. The story continually reinforces an important part of this company's culture. We must not ship crap. There isn't a corporate values statement on the planet that so brutally and beautifully defines the culture of a company.

Most organizations don't seem to realize the importance of these silent culture definers and the role they play in the overall scheme of things. Michael also does a great job at describing how the culture chart has a deep impact on the organization and particularly on the best of your team members:

Culture assessment is an information game and it's never over. Your job is to continually situate yourself in such as a way that, as quickly as possible, you can assess subtle changes in the culture of your company. I wasn't concerned when Netscape started losing market share to Microsoft. I didn't sweat it when the stock price stalled. The reason I started thinking about my next gig was, months before either of these two events occurred, one of the lunchtime bridge team left. The game stopped. The small group of four no longer spent a long lunch quietly, unknowingly defining the culture of the company and everyone who was watching noticed. They noticed when one of those who had humbly done the work that defined the company no longer believed enough to stay.

If you've been reading along so far it does end up sounding like these guys put in a great deal of effort to create an amazing work culture around them; but most of these kickass managers or culture defining team members I've had the privilege of working with or seeing in action, hardly have any such specific intent in mind. The same post on culture charts describes the intent with which the real culture definers work:

The people who are responsible for defining the culture are not deliberately doing so. They do not wake up in the morning and decide, “Today is the day I will steer the culture of the company to value quality design”. They just do it. The individuals who have the biggest impact on the culture and company aren't doing it for any other reason than they believe it is right thing to do, and if you want to grow in this particular company it's a good idea to at least know who they are and where they sit. You need to pay attention to this core group of engineers because as they do, so will the company.

These difference makers, culture definers or whatever it is that you want to call them, are not really thinking of changing the organizational culture, making their teams flock, developing deeper bonds between team members, saving your world or any of that crap. Helping the team in whatever small way they can; an awesome dinner or a nice game of bridge; that's all they have on their minds; especially when they are dealing with their teams.

After our brief digression into books like 'Peopleware: Productive Projects and Teams' and the post on the Culture-chart let's get back to what we started off with in the first place, shall we?

Men In Black. That's where we started, and we said most managers are like them; didn't we? Ok, here's how it goes:

Kay: We do not talk about project timelines in public! It distracts people in the the team and takes their focus off the real work. Jay: Man, we ain't got time for this cover-up bullshit! I don't know whether or not you've forgotten, but there's a stupid client who wants all this work done, deployed and running on production in three weeks... Kay: There's always an impractical, slightly lost, confused client that is about to wipe out all chances of success on all miserable little projects like this one, and the only way these developers can get on with their happy lives and code away to glory is that they Do... Not... Know about it!

Or should we say:

Kay: We do not talk about project timelines in public! It distracts people in the the team and takes their focus off the real work. Jay: Man, we ain't got time for this cover-up bullshit! I don't know whether or not you've forgotten, but there's a stupid client who wants all this work done, deployed and running on production in three weeks... Kay: You want to play a game of bridge? Hungry? Let's go grab a sandwich.

And before you know it, magic! The team suddenly has six months to ship, the pressure of deadlines has disappeared, people are nicer to each other and work is fun.

Here's another one:

Kay: We do not talk about crappy status reports and project plans in public! It distracts people in the the team and takes their focus off the real work. We help them ship! Jay: Man, we ain't got time for this cover-up bullshit! I don't know whether or not you've forgotten, but there's a vice president sitting at the client's office who wants who wants a weekly status report and a detailed project plan... Kay: You want to play a game of bridge? Hungry? Let's go grab a sandwich.

And before you know what happened, magic again! The neutralizer has been used on the client; those specific details have been wiped off their memory; they don't miss those status reports anymore and everyone seems to be getting the real work done.

The next time your manager calls a lengthy meeting and talks to you about how he plans to change the culture of the organization; chances are, that he has just picked up an inspirational management book from somewhere and is pulling on his awesome-manager-mask. Simply put, most probably, he's faking it. The ones who really change cultures, hardly ever plan to do it. In fact, they tend to do it one small step at a time, without even their own conscious knowledge that they are doing it.

Unlike the ones who spend their careers trying to pull acts of heroism, I've had the pleasure of seeing the real heroes in action working rather silently; taking one step at a time. These are genuinely inspirational individuals who influence and move others without even knowing or realizing that they do.

They will change you, they will influence you, they will make you work harder and turn into better human beings; and the funniest part of it is; you won't even realize they're doing that. I didn't; till I looked really hard and then I saw a couple of them; in action. They were right there; in my very own life and they were making silent, subtle changes in it.

Does going to office on a Monday morning suck? It always used to? If you answered yes chances are you haven't had the pleasure of seeing them in action or the pleasure of working with them. I have one little advice for you; be patient; and keep looking; the world has a very limited supply of these guys and if you're lucky you just might find them. On the other hand, if you do love and feel excited about coming to work on a Monday morning chances are that you have some of these guys around you.

If you do happen to have some of these guys around you, chances are that they are saving your world right now and you don't even know it. In fact, if they are genuinely good at this stuff, there is indeed a high probability that they themselves, don't know it. Now go find them; watch them closely and learn from them. I wish you good luck.

At Multiplitaxion Inc, a lot of us in the product teams were busy building products and shipping features. It was a great team of thick-skinned, competent, one-man armies who felt very strongly and passionately about the products being built. When features didn't work they were out there, willing to take calls in the middle of the night and support what they had written. This was a team of really hard working developers who had a lot on their plate.

They were building the product, enhancing it, supporting it and they were out there to listen to the customer and help them when they had a problem. Obviously they were busy; and because they were all busy, when we started marketing the product to the mainstream market we came up with the idea of having a different team take up the marketing websites, the product videos and the blogs.

The idea seemed innocently simple, efficient and effective at first; and then it happened.

Websites with (In)Frequently Asked Questions started springing up. Blogs having the same content as the marketing website started showing up. Posts started to including a very strong marketing touch to them. Below, I provide an example of one of the many posts that multiple individuals in the team started coming up with:

Do you know the [data-about-your-organization-that-the-application-provides-reports-on]? Or, do you know if [more-data-reported-the-application-includes]? "No"? Then I think you should. Trust me, this is a crucial piece of information that every organization must have. After all, [data-that-the-application-provides] is important for any organization. Your next question would be how I can capture this information. And answer is through [product-name].

The above example, is a rather small one. Overall, the whole bastardization of Blogs, Wikis and even Forums for the purposes of traditional marketing began and that was indeed starting to become a little frustrating for me. On the bright side, however, that wasn't the first time in this history of internet marketing that this was happening. In fact, we weren't even close to misusing blogs compared to a lot of other big names who had indulged into what Wikipedia defines as 'fake blogs':

A fake blog (sometimes shortened to flog or referred to as a flack blog) is an electronic communication form that appears to originate from a credible, non-biased source, but which in fact is created by a company or organization for the purpose of marketing a product, service, or political viewpoint. The purpose of a fake blog is to inspire viral marketing or create an internet meme that generates traffic and interest in a product, much the same as astroturfing (a "fake grassroots" campaign). Fake blogs are corrupted forms of public relations, which as a discipline demands transparency and honesty, according to the Public Relations Society of America's code of ethics and the Word of Mouth Marketing Association's code of ethics. Authenticity and transparency are important in social networking and blogging, as these codes of ethics attest. As social networking tools gain in popularity, corporations and special-interest groups legitimately use their own blogs to promote company agendas without cloaking their identities (one such example is http://www.blogsouthwest.com, a blog sponsored by Southwest Airlines and written by its employees). One notorious example of identity cloaking, resulting in a fake blog, was exposed when Edelman, an international public relations firm, created a fake blog in 2006 called Walmarting Across America. It was purportedly written by two Wal-Mart "enthusiasts" who decided to journey across the United States in an RV, blogging about the experience as they visited Wal-Marts along the way. While two people actually did travel across the United States in an RV, the publicity stunt was revealed to be paid for by Wal-Mart, a client of Edelman.

But, like all things in life, the internet and the software development world in general are real places where common sense, simplicity, transparency and the laws of karma eventually prevails. Tim Nudd describes how Sony was ripped and hugely criticized for their acts of trying to bastardize blogging as a medium to do fake promotion of PSP. He reports the whole incident rather articulately:

All I Want for Christmas Is a PSP pretends to be a fan blog (run by a guy named "Charlie", who says he's helping his buddy Jeremy get a PSP for Christmas), but it's a poorly disguised marketing effort—the URL is registered to Zipatoni. Visitors to the site are letting Sony have it in the comments. Says one: "If you want a PSP badly enough you should get together with an ad agency. Then try to sell the product through a lame website while attempting to speak down to what you consider your target audience." Even more comical: "Charlie" keeps posting his denials, in pseudo hip-hop speak. More than once he writes, "yo where all u hatas com from... juz cuz you aint feelin the flow of PSP dun mean its sum mad faek website or summ... you-all be trippin." Pathetic. Over at the Something Awful message boards, a commenter makes a good point about this effort: "Makes you wonder why they can't cough up the $8 to do private registration, to keep people from easily seeing that their 'blogs' are owned by promotional companies."

Tim describes how the whole Sony PSP episode finally ended:

Sony has now posted this mea culpa on the site: "Busted. Nailed. Snagged. As many of you have figured out (maybe our speech was a little too funky fresh???), Peter isn't a real hip-hop maven and this site was actually developed by Sony. Guess we were trying to be just a little too clever. From this point forward, we will just stick to making cool products, and use this site to give you nothing but the facts on the PSP. Sony Computer Entertainment America.".

Singling out Sony in the whole post seems like a lame thing to do. There have been many more including Wal-mart, Coke and many others. Internet mavens are in fact pushing so far as pursuing criminal prosecution for organizations which indulge in the act of marketing through false blogs. 

What we were doing at Multiplitaxion Inc, was nowhere close to fake-logging; but we had made a big mistake; while our PR teams and business analysts wrote the blogs they forgot two cardinal rules of blogging:

1. Blogging is like life – nobody cares about you or your products; unless you have something for them.
2. Blogging is like great sex – it is very difficult to fake the passion.

If there was one word which described what we were indulging in, it wasn't fake-blogging, it was lame-blogging. Thankfully, we failed early. Before any of these blogs went live we asked our PR team to stop writing posts till they genuinely connected to the product and if they couldn't connect to the products genuinely, they didn't have to write about the product.

Crowd-sourcing, collaboration, social networking and blogging might be seen by organizations as mediums to promote their products and there is absolutely nothing wrong with it. A lot of organizations including Microsoft – through ASP.NET and Channel 9 – do this rather elegantly and honestly. A lot of individuals including Scott Guthrie, Phil Haack, Scott Hanselman and many others also blog honestly, passionately and informatively. They provide genuine knowledge and value along with some really honest feedback to their readers, even when they are talking about their own products or products built by Microsoft.

When people visit your blog, it is your personality, knowledge, spine and conviction that they are relying on. The whole I-was-paid-to-say-good-things-about-my-organization-and-their-products-so-I-did argument doesn't work in the long run. If you want to write about your organization, know your organization inside out and write about crap that goes on in your organization while you sing it's praises. If you want to write about your products break the good news and the bad news; in fact the guys at 37signals suggest that you publicize your screw-ups.

With blogs you are not just pushing content. You're participating in a discussion and you're contributing. You're interacting and connecting with people. You are reaching out and in more ways than one ways, you are asking for their involvement, interaction, time, help or some combination of one or more of these. When you reach out the a huge group of people asking them to give you time, involvement, help, or combinations of one or more of these, you are judged by your integrity, transparency and honesty more than anything else. If communities  can donate a staggering four million to Wikipedia they can also call the Sony PSP blog pathetic and laugh at wall-mart for being caught with it's pants down.

So, go ahead and assume that marketing pitch on your posts and consider your readers to be first grade idiots; go ahead and write those crappy FAQs; go ahead and create fake blogs; go ahead and share your frustration, write your depressing diary or genuinely contribute and participate by being open, honest and transparent. The choices are all yours; make them wisely; because your users will make theirs based on yours. They may decide to abandon your blog, send flame mails, angry-comments or grace you with more visits, appreciation, comments with honest opinions and interesting discussions. Just like everything else, blogs follows the rule of karma – what goes around comes around; In fact, it often comes around 10x magnified.

Next time before you press that submit button, think. Question yourself about what it is that you're sending out - is it knowledge, inspiration, experience, wisdom, lie, sugar-coated-marketing-message-which-you-are-being-paid-to-spread, depression, frustration, random HTML that will get you a higher Google ranking and then cause disappointment to the visitors when they land on your website or is it something else? What ever it is that you're sending out, do you really want it multiplied 10x and coming back in your life? If not, may I suggest that you take your mouse far away from that publish button and delete the post immediately.

Whether you're an individual or an organization, your blog is your third place and one of the best reflector of your personality, don't bastardize it. Write with conviction, add genuine value and then support what you write; after all, what goes around comes around. Now go write something that you genuinely believe in or are genuinely passionate about. Seriously.

To surrender or not to surrender is an age old question in the game of chess when mere mortals are playing; but the most veteran grand masters of chess gracefully drop their kings announcing their surrender as soon as they sense guaranteed defeat. The grand masters often don’t act optimistic and hope that their opponent will make a foolish mistake which in turn will cause the game to completely toss around giving them an undeserving victory. When they know they’ve lost, they surrender, back out and end the game with a graceful acceptance of defeat.

The art and discipline of considering defeat as an integral part of the game also exists in the world of mountain climbing. One of my CEOs and an individual I personally looked up to during the early days of my career, and still do, describes his experience on a climb in our company intranet (I’m not sure if he would like me to publish his name or names of others involved in the climb so names have been changed for obvious reasons):

While we could see the summit, we knew that we were at least an hour away. There were dark thunderstorm clouds looming around the summit - they had appeared gloomy from a 1,000 feet below they looked morbid from where we stood. With tired limbs, faint hopes but determined minds [Jack] and I started climbing towards the summit. However, by 12:15 we were barely at 13,700 feet a good 500 feet short of the summit. [Daniel] and [Rogers] had heard from other guides in the mountain that the weather prediction called for heavy thunderstorms in an hour or so and they sternly signaled us to turnaround and head back. To make matters worse, they had heard that due to the sunny day, the snow had turned slushy further down the slopes, if it continued remaining warm, we could face treacherous conditions - snow sinking - one where the snow is so deep and loose that one falls right through it and sinks under. We pushed our luck to see if our guides will let us buy a bit more time but [Rogers] was obstinate and conveyed his point by saying: My job is not to take you up, but bring you down safely. The mountain will be here, my job is to be sure you can be back for another climb; and to soften the blow further said Jamling Tenzing (Sherpa Tenzing’s son) tried 11 times to summit Mt Everest - so some patience might be in order on our part While these were pacifying words, it did not help us overcome the anguish that we came so close but due to paucity of time could not scale the peak. We were also glad that thanks to our guides prudent judgment prevailed. Most climbers get into trouble because they ignore sound, sagacious advice. We took a brief respite and reluctantly started walking back.

Let’s snap back to the world of software development, shall we? Look around and I’m sure you’ll a rare very-few organizations, managers or even veteran developers giving such sound, sagacious advice to young and budding developers. Most organizations and managers instead seem to be much more optimistic and seem to push a you-can-do-it attitude even in case of obviously desperate and beyond repair situations.

We like to think of our kick-ass teams and one man armies as ‘super-heroes’ who can change the fate of the project by their sheer hard work and determination. We seem to push the idea that physical limitations like the iron triangle just don’t exist and heroes can pull out successful projects like magicians pull rabbits out of their hat or overcome all limitations like the Hollywood hero overcomes all difficulties before the movie ends. We push on, and turn simple mistakes and small defeats into disasters, merely by not accepting them in the first place.

Legendary author Steve McConnell considers heroism to be one of the 36 classical mistakes in book ‘Rapid Development: Taming Wild Software Schedules’. He explains:

Some software developers place a high emphasis on project heroics, thinking that the certain kinds of heroics can be beneficial (Bach 1995). But I think that emphasizing heroics in any form usually does more harm than good. In the case study, mid-level management placed a higher premium on can-do attitudes than on steady and consistent progress and meaningful progress reporting. The result was a pattern of scheduling brinkmanship in which impending schedule slips weren't detected, acknowledged, or reported up the management chain until the last minute. A small development team held an entire company hostage because they wouldn't admit that they were having trouble meeting their schedule. An emphasis on heroics encourages extreme risk taking and discourages cooperation among the many stakeholders in the software-development process. Some managers encourage this behavior when they focus too strongly on can-do attitudes. By elevating can-do attitudes above accurate-and-sometimes-gloomy status reporting, such project managers undercut their ability to take corrective action. They don't even know they need to take corrective action until the damage has been done. As Tom DeMarco says, can-do attitudes escalate minor setback into true disasters (DeMarco 1995).

Of-course, Steve McConnell isn’t the only one with a thick skin towards failure. The folks at 37Signals are also particularly unashamed about giving up. In fact they go so far as saying that ‘giving up is good’:

Here’s the problem: You agree that feature X can be done in two hours. But four hours into it, you’re still only a quarter of the way done. The natural instinct is to think “but I can’t give up now, I’ve already spent four hours on this!”. So you go into hero mode. Determined to make this work, but also embarrassed that it isn’t already so. So the hero grabs his hermit cape and isolates himself from feedback. “I really need to get this done, so I’ll turn off IM, Campfire, email, and more for now”. And some times that works. Throwing sheer effort at the problem to get it done. But was it worth it? Probably not. The feature was deemed valuable at a cost of two hours, not sixteen. Sixteen hours of work could have gotten four other things done that individually were at least as important. And you had to cut the feedback loop to avoid feeling too much shame, which is never a good thing to do. That’s where the concept of sunk cost gives us a guide on what to do. It doesn’t matter what you’ve already spent. That time and money is gone. It only matters whether spending what’s left is worth it or not. Business school 101, but one of the hardest lessons to internalize. In other words, stop being so afraid of calling it quits. You’re playing to win the full season, not a single game. Every time you play the hero card, you’re jeopardizing the next game.

While the folks at 37signals talk in terms of two hours and sixteen I’ve seen organizations carry on with huge teams for months and even a couple of years just because the manager and individuals in the team were too ashamed to admit that they had failed. Heroism is exactly the kind of thing that turns simple failures into irrecoverable disasters.

You may not be a mountain climber or a chess player, but if there is one thing you must learn from both these fields, particularly when it comes to your project, it is this: When your logic and gut tells you it is not possible to win or to make it to the end successfully, give up; and use the time and energy saved for the next battle. After all, if you’re around, you can always be back for another climb or another game.

Don’t ruin your career chasing the Hollywood-like-dream of being a hero who fights difficult times and always emerges a winner. Get real; give up a battle or two if you must. Failing is good, as long as you Fail early and Fail often. When you know you won’t make it or when failure is inevitable, surrender shamelessly; move on to the next game and play harder. Don’t waste time trying to be a hero who cannot fail.  After all it’s about winning the full season, not every single game.

With this thought, I wish you, dear reader, a very happy life full of defeats, victories, fulfilling challenges, satisfying experiences and above all relentless passion to pursue whatever it is that you love doing.

I’ve often insisted that project managers should write code and lead from the front. As you dive in, roll your sleeves and fight the battle hand in hand with your team it is equally important for you to consider them as comrades and not mere soldiers ready to charge or strike at your command.

When engineers, sometimes even smart and able ones, come to you expecting you to take their decisions for them it is often very tempting to take a decision and establish your ‘seniority’. The more you do it, the stronger you feel about your role in the organization and the dependence of your team on you. After all, it makes you feel wanted and it makes you feel in control. A whole lot of managers I’ve seen in multiple organizations around the world enjoy their involvement in any decision that happens in the project. Do you, dear reader, love being in charge of the driving wheel in your project or organization?

If you answered yes to that question with knitted brows wondering what’s so wrong with your being in-charge and in-control of your project, what you may not realize however, is that you might be, silently introducing the culture of mitigated speech in your organization.

Joel Spolsky describes how he himself, failing to give up the driving wheel on the right time and giving a careless tacit approval for a feature to be built in the product, nudged his team to start working on the feature without giving a lot of thought on whether the feature should have been actually built in the first place. He ends his post with a resolution to the problem that takes a lot of conviction on the part of the manager. His suggested recommendation is simple:

The solution, of course, is what I’ve been saying all along. STOP FRIGGIN’ LISTENING TO ME. I don’t know what I’m talking about. If you work for me, you’re welcome to get my advice, but you have to make your own decision because chances are you’ve thought MUCH MORE about the issue than I have and in fact we probably hired you because you’re smarter than I am.

The idea of lending control to your team members might sound a little absurd and often makes young, budding and even the most veteran leaders just-a-little insecure at first but is has a lot of obvious advantages:

1. It frees you up to take bigger and better challenges.
2. It enables your team to make smart and honest decisions.
3. It helps avoid the perils of mitigated speech.

Malcolm Gladwell, in his latest book, Outliers, describes how important handing over the driving wheel to juniors in your team is when he talks about the perils of mitigated speech. He explains:

Mitigation explains one of the great anomalies of plane crashes. In commercial airlines, captains and first officers split the flying duties equally. But historically, crashes have been far more likely to happen when the captain is in the “flying seat”. At first that seems to make no sense, since the captain is almost always the pilot with the most experience. But think about Air Florida crash. If the first office had been the captain, would he have hinted three times? No, he would have commanded – and the plane wouldn’t have crashed. Planes are safer when the least experienced pilot is flying, because it means that the second pilot isn’t going to be afraid to speak up.

The next time someone walks up to you with a Should-We-Build-This-Feature or for that matter any question, take him to a whiteboard and turn the table on him by triggering a I-am-not-sure-lets-see-what-you-think brain-storming-session. Discuss the pros and the cons, give recommendations, provide suggestions but make sure that it is not you who is making the final decision. It is your team that has to learn to do that in the long run. 

Long story short, unless you are heading for a crash, lead from the front, inspire the team, enable them, take sizable development tasks on your project, but don’t always take control of the driver’s wheel, specially when it comes to taking decisions.

If you want to lead, find lots of kickass programmers and one man armies who are capable of driving projects to successful ends. Mentor them and then leave the driving while in their safe and able hands. You can’t be driving multiple cars at once anyways.

Don’t handhold individuals on their way to success. Empower them to have their own share of mistakes and their own share of failures as they slowly attain success without any handholding. If you’ve picked a kickass team, got them to flock well in the right culture, and mentored them genuinely, they will take control, ownership, responsibility and start driving your projects towards success faster than you can think. Go ahead, lead from the front; but remember; you don’t always have to be at the driver’s wheel, taking every single decision in your project, in order to do that. 

During my work at multiple organizations, client offices and multiple cities around the world, I’ve seen individuals get nervous while talking to their CEO’s and Managers. Individuals fumble, sugar-coat discussions and avoid arguing with their clients. Some of them merely hint towards what they believe is correct and then decide to keep their mouths sealed. With time, they turn either disconnected or completely nervous and reluctant to give their ideas.

At the first glance you would classify them as spineless individuals lacking conviction but monitor them closely and you’ll figure out that these guys are indeed capable of fighting harder battles and taking up bigger challenges than their sophisticated counterparts who just happen to be a little more articulate with words.

I could go on and on about my stories on how people not ‘speaking up’ at the right time can lead to project failures and colossal-screw-ups. Here’s one:

Fred was asked by Multiplitaxion Inc, to come up with a data access framework that would assist them build multiple other applications on. Fred had done a couple of consultancy projects before but this was his first time at framework development and he struggled for over a couple of years with a decently big team of programmers. Time flew as Fred struggled. Two years later, Fred had failed; and that, those who understand software, will tell you is not such a bad thing after all. Two years later the stars aligned and a proposal showed up requiring the exact same features Fred and his team had been assigned to build. Fred was asked if the framework would ‘fit’ and if they could roll out the framework and build other enterprise applications using the framework. Fred hesitantly and reluctantly told the management that they 'could indeed build other applications on top of the framework but they would have to do ‘some refactoring’ and tweaking before the application became fully scalable; or something to that effect. Reality of it was that data access framework had broken windows all over the place and was snowballing into one large crappy piece of application right in front of the entire team. The team was clearly not as optimistic as Fed or the management and yet the members barely expressed their concerns in statements like - ‘maybe we ought to change the database server’, ‘maybe we ought to bump up the code quality’ and the like; and then they continued working. When the people who sign the paychecks looked at the framework they weren’t really impressed; but they had already been told that the application required ‘some refactoring’ before it would become fully scalable. It crashed here and there a couple of times and then individuals from the management level wrote back to the team appreciating the team’s effort and mentioning in the passing that the application needed to get better and they were sure it would get better with time. The application rolled out to the client, in semi-broken, fragile state where shaking it up really hard would start breaking things all over the place; this is how far things went and in all this time no-one ever mentioned that the emperor was in fact naked.

If you were reading that real life story that I was a personal witness to from the outside you would think that everyone in the whole episode was either spineless, lacking conviction or both; yet clearly that is not the case. 

Malcolm Gladwell feels that this communication issue is in fact the reason for most airplane crashes happening around the world. The linguists he interviews for his latest book Outliers, gives this phenomenon a name:

“Mitigated Speech”, which refers to downplay or sugarcoat the meaning of what is being said. We mitigate when we’re being polite, or when we are ashamed or embarrassed, or when we are being differential to authority. If you want your boss to do you a favor, you don’t say, “I’ll need this by Monday.” You mitigate. You say, “Don’t bother, if it’s too much trouble, but if you have a chance to look at this over the weekend, that would be wonderful.” In a situation like that, mitigation is entirely appropriate. In other situations, however – like a cockpit on a stormy night – it’s a problem.

Outliers provides chilling transcripts from the black boxes of crashed airplanes which clearly show how the plane crews were busy indulging in mitigated speech and worrying about what the captain or their air traffic controllers would think even when their plane was rapidly approaching a disastrous crash.

Outliers also does an amazing job at doing is describing the importance Power Distance Index (PDI) and cross culture mitigations in airplane crashes. The book describes how the country in which you were brought up and your culture will eventually have an influence how you deal with crisis situations. In Outliers, Malcolm uses the example of Columbian pilots landing an airplane which is low on fuel to illustrate how people from different countries and cultures deal with authority and superiors, even when involved in crisis situations.   A lot of it also ends up being very relevant even in the software development world:

There was something more profound – more structural going on in the cockpit. What if there was something about the pilots’ being Columbian that led to the crash? “Look, no American pilot would have put up with that. That’s the thing, Ratwatte said. “They would say, ‘Listen, buddy, I have to land.’”.

Ever wondered why a huge number of Indian programmers fail miserably at communicating the accurate health of their project to their counterparts around the world and why some of them fumble all over the place in conference calls with their clients? Read Outliers and you might just stumble across that answer and many more. 

The book provides stories of how the Korean airline turned from the worst airline with the highest number of air-crashes to an airline which was highly reputed and very safe simply by overcoming mitigation resulting out of their fundamental underlying cultural background. According To Malcolm mitigation has been the primary reason for most air-crashes in the history of the aviation industry. He explains:

Combating Mitigation has become one of the great crusades in commercial aviation in the past fifteen years. Every major airline now has what is called “Crew Resource Management” training, which is designed to teach junior crew members how to communicate clearly and assertively. For  example, many airlines teach a standardized procedure for copilots to challenge the pilot if he or she thinks something has gone terribly awry (“Captain, I’m concerned about…”, Then, “Captain, I’m uncomfortable with…”, And then if the captain still doesn’t respond, “Captain, I believe the situation is unsafe.” And if that fails, the first officer is required to take over the airplane.) Aviation experts will tell you that it is the success of this war on mitigation as much as anything else that accounts for extraordinary decline in airplane incidents in recent years.

After years of airplane-crashes the aviation industry may have learnt the lesson; but after iterating in the infinite loop of failure for years neither software-developers nor software development shops seem to be putting in any conscious effort to battle mitigation.

Do you have a problem of mitigation in your team? Do you yourself indulge in mitigated speech at work when dealing with your seniors or while making your juniors feel good, even when things are badly messed up?

If you answered yes to any of the above questions go walk up to your manager and express your opinions bluntly and openly or pass on some honestly blunt constructive criticism to your juniors. I dare you.

On a serious note, Don’t underestimate the perils of mitigation in software development. Create an open culture where mitigated speech is discouraged and ideas are thrown out in the open, freely. Rage your battle against the problem of mitigated speech before it leads your future projects to disastrous crashes. I wish you good luck.

When I first figured out how Resume Driven Development works I naively assumed that I could blame it for every project that is mesh of super complex technologies and tricky code. After experiencing it for the first time, I assumed that for every project that used countless layers of abstractions, indirections, irrelevant technologies held together using really weak band-aids, there had to be one or more team members desperately trying to build their resume or drooling over the latest cutting edge technology and frameworks that are in Beta.

It was then that I met a different kind of programmers. These could not be defined as full fledged proponents of Resume Driven Development, yet it was the kind whose mere involvement in any projects could turn their projects into what we shall refer to as ‘Project Rocket Science’:

These are programmers  who make a serious face and talk about ‘Enterprise Development’, ‘Best Practices’ and ‘Scalability’. When I say ‘talk’ I’m not referring to the ‘bring-up-in-a-white-board-session-and-brain-storm-quickly’ kind of a talk. I’m talking about start-a-formal-document and discuss-for-a-few-weeks-or-maybe-even-months kind of talk. Or for that matter make-a-big-deal-about-it and don't-start-coding-till-you’ve-figured-it-out kind of talk. After all, this thing is really important and these individuals just ‘have to’ get it right before they start coding.

At Multiplitaxion Inc, we had a hard time convincing a few of these programmers to try out Ruby on Rails. Before individuals wrote a single line of ruby code discussions and arguments pertaining to ‘is-ruby-on-rails-scalable’ began. The discussions and arguments lasted for weeks. Examples of ‘enterprise applications’ written in Ruby On Rails were demanded and provided in long mail trails. Days went by; weeks later we were moving in circles trying to know for sure we can write ‘Enterprise Applications’ using Ruby On Rails.

Damien Katz, has an interesting take on zealotry and excessive concern about scalability and building ‘enterprise level application’. Damien believes that if you find yourself making a big deal about some of these topics, chances are that you're a crappy programmer and you don’t even know it:

You know those crappy programmers who don’t know they are crappy? You know, they think they're pretty good, they spout off the same catch phrase rhetoric they've heard some guru say and they know lots of rules about the "correct" way to do things? Yet their own work seems seriously lacking given all the expertise they supposedly have? You don’t know any programmers like that? Come one, you know, the guys who are big on dogma but short on understanding. No, doesn’t sound familiar? Then here are some signs you're a crappy programmer and don't know it: Java is all you'll ever need: You don't see the need for other languages, why can't everything be in Java? It doesn't bother you at all to see Python or Ruby code that accomplishes in 10 lines what takes several pages in Java. Besides, you're convinced new language features in the next release will fix all that anyway.(BTW, this can be almost any language, but right now the Java community seems most afflicted with this thinking) "Enterprise" isn't a punchline to you: This is serious stuff dammit. "Enterprise" is not just a word, it's a philosophy, a way of life, a path to enlightenment. Anything that can be written, deployed or upgraded with minimal fuss is dismissed as a toy that won't "scale" for future needs. Meanwhile most of the real work in your office is getting done by people sending around Excel spreadsheets as they wait for your grand enterprise visions to be built.

It’s a rather wordy and highly opinionated post. I encourage all you Java developers to flame Damien (not me) for all of it. On a serious note, without being specific about any language or platform, the whole Enterprise-and-Scalability-Talk is highly overrated in a lot of development communities around the world.

What is even more frustrating is that the people talking about these topics the most are the shittiest programmers, incapable of creating applications that can support a trivial twenty concurrent users. Ted Dziuba feels so utterly frustrated about people clueless about scalability making a big deal about scalability that he loses a track of language in his rather foul mouthed yet passionate, hilarious and honest post:

Engineers love to talk about scalability.  It makes us feel like the bad ass, [swearword]-swingin' [swearword] that we wish we could be. After we talk about scalability with our co-workers (Yeah, Rails doesn't scale!), we flex our true engineering prowess by writing a post about it on our blog.  Once that post hits Reddit, son, everyone will know how hardcore you really are.  Respect. People Who Talk Big About Scalability Don't Need To Worry About It. Fact:  every chest-thumping blog post I have seen written about scalability is either about architecture, Memcached, or both.  Some a#@hole who writes shitty code starts pontificating about "scalable architecture" with data storage, web frontends, whatever-the-f#@k.  Dude, your app isn't having scalability problems because of the architecture.  It's having scalability problems because you coded a ton of N^2 loops into it and you're too self-important to get peer reviews on your commits. And let's not forget the tools who discover Memcached for the first time, install it on a web server, and notice how fast their app runs now.  Yeah, welcome to the modern age.  Hope you know what a cache expiry policy is. If You Haven't Discussed Capacity Planning, You Can't Discuss Scalability. You don't need to worry about scalability on your Rails-over-Mysql application because nobody is going to use it.  Really.  Believe me.  You're going to get, at most, 1,000 people on your app, and maybe 1% of them will be 7-day active.  Scalability is not your problem, getting people to give a shit is.

The folks at 37Sginals are much more conservative with their language; but they make the exact same point that getting-people-to-give-a-shit is indeed your biggest problem, with a rather nicely worded and elegant chapter in their book. They explain:

"Will my app scale when millions of people start using it?" Ya know what? Wait until that actually happens. If you've got a huge number of people overloading your system then huzzah! That's one swell problem to have. The truth is the overwhelming majority of web apps are never going to reach that stage. And even if you do start to get overloaded it's usually not an all-or-nothing issue. You'll have time to adjust and respond to the problem. Plus, you'll have more real-world data and benchmarks after you launch which you can use to figure out the areas that need to be addressed.

I’ve dealt with a few performance issues myself. I’ve also seen a few kick ass programmers kick some serious butt by tweaking the database to it’s limit and take caching to it’s limit. What’s fundamentally different was that in all these cases, we invariably waited till it became a real problem. When it did become a real problem we got into a room, white boarded the issue and got it fixed without making a big noise about it.

I’ve done this with two different teams in over three projects and the one conclusion on scalability that I’ve reached is this; if ‘Enterprise’ and ‘Scalability’ are big words in your organization you’re definitely doing something wrong; or maybe you just have too many individuals in your team who cannot write code or ship.

User your common sense, avoid un-necessary complexity and write simple code. Chances are you won’t even run into scalability problems till your application grows to a level where you’ll actually love having and fixing scalability issues.

The next time you talk about setting up a cluster for load balancing, building an enterprise application or utter the ‘S’ word, show me a million users signed up for your application or a ‘real scalability problem in production’ and we can talk ‘scalability’. Till you can do that, just keep those N^2 loops or that funny-little-short-cut out of your code and you’ll be good.

You can flex your engineering muscle and continue whining about Scalability, Best Practices and ‘Enterprise’ applications all you want. In the meanwhile we’re going to write some shitty software with bugs, get something done, and ship stuff that people like using. You know what; we’ll even have fun doing it. I’m not all all that into talking about ‘Enterprise Application’. I don’t give a shit about ‘Scalability’ till it becomes a real problem; and believe me that’s not as bad as it sounds.

When I walked into my first day at work at my very first organization I literally called my manager ‘sir’. Early on in my career I saw a few ‘friendly managers’ wanting a lot of your ideas and feedback without giving you due credit for any of them when they worked. Then there were others who were primarily not even interested in feedback and ideas. There were days in my career where you felt like you were a part of army of robots working for a boss, who was supposed to be the only one capable of thinking, coming up with awesome ideas or getting anything useful done.

Over a period of time as I lived the yes-sir life I realized how messed up it was. Slowly I turned myself into an opinionated individual who wasn’t ashamed to express his opinions. Long story short – I developed a thicker skin and to an extent a stronger spine to speak my mind.

Even today as I look around I see countless individuals lacking the courage and the conviction to speak their mind at their workplace. If I were to sample the last fifteen organizations I’ve worked at, visited or been at in the past, at least thirteen of them had the problem so blatantly visible that you could hear whispers of dissatisfaction in the corridors even during your first visit to the organization.

Most of these organizations were doing something so blatantly wrong and stupid that even the junior most developer writing HTML knew it but they’d rather prefer to keep their mouth shut. No-one seems to have the conviction to bring the problems out in the open and throw them out there such that they would have to be tackled.

Scott Berkun describes the problem of how problems exist within the corridors of most modern organizations, where everyone knows about them but no-one brings them out or discusses them openly. Scott explains this issue much more articulately than me in his post on ‘how to fight management incompetence’. He explains:

Since my cranky post last week titled Do we suck at the basics? I’ve had an eye out for writing on incompetence and suckage. Over at Harvard Business John Baldoni, author of a slew of bestsellers, had a recent post called How to fight management incompetence. He offers three bits of advice: Link competency to promotion Hold people accountable Keep competencies relevant. Ok. Got it. This is good and sensible, sure. But the platitude part is easy. The real thing missing is conviction. Being accountable takes courage, something that doesn’t come with a degree or years of experience. Plenty of cowards have lurked in executive circles for decades. I believe most people just don’t have the guts to do the thing any idiot knows is right and this includes many managers. How many courageous people do you know? It can’t be more than 1 out of 10, maybe 1 out of 5. There is no special courage pill yet for VPs, so they have the same kinds of spines as the rest of us. The big incompetence crime committed by VPs is leaving incompetent managers in place for too long. My theory: by the time the CEO knows a VP stinks, the whole org has known about it for months. The smart people have been making plans to leave or are working to cover their assess. By the time the CEO gets around to taking action, it’s way too late. And often the action taken is whitewashed: no mention is made of how the VP or middle manager utterly failed (e.g. “Fred has decided it’s time for something new.”) The denial lives on, the lie propagates, making it easier for more denials and lies the next time around. All most employees want is for the people above them to be honest more of the time. Even if things stink, honesty makes it possible for people to maintain their sanity (”ok. So you at least see what I’m seeing. Thanks.”). But it also makes solutions possible, since people are trying to solve the same issues. Bob can go to his boss with suggestions and feedback only if he understand what it is his boss is really concerned about.

Walk down the corridors of any of these modern software development shops and you’ll see hush-hush discussions of things that stink and no-one willing to discuss them openly. Openness and transparency is something you cannot preach to your team. You can only set up transparency and flatness by making it a way of your own life and then expecting your team to reciprocate.  Of course pushing for transparency and success in projects is not as easy as it sounds. It requires conviction, genuine belief and above all a very strong spine at all levels within the organization.

Jeromy Carriere advices managers and programmers to develop a stronger spine by pushing them to turn themselves into ‘intrapreneurs’. He explains:

When I get frustrated with the ponderous bureaucracy characteristic of large enterprises, and long for the hopeful, entrepreneurial and innovative environment of a startup, I lean on a set of principles that try to bring the spirit of a startup, through the actions of individuals with dreams and drive, to any organization. Until recently, I didn’t know these principles have a name – Intrapreneuring. Intrapreneuring is an idea initially formulated by Gifford Pinchot in the 70s, and is based on the idea that anyone can innovate, be entrepreneurial, within a corporate environment. Mr. Pinchot described ten commandments to be followed by the intrapreneur: Come to work each day willing to be fired. Circumvent any orders aimed at stopping your dream. Do any job needed to make your project work, regardless of your job description. Find people to help you. Follow your intuition about the people you choose, and work only with the best. Work underground as long as you can – publicity triggers the corporate immune mechanism. Never bet on a race unless you are running in it. Remember it is easier to ask for forgiveness than for permission. Be true to your goals, but be realistic about the ways to achieve them. Honor your sponsors.

It doesn’t matter what your role is or what it is that you do, chances are that you’re going to make decisions even when you are in a corporate environment with a very limited and well defined role. The decisions could be as simple as picking up variable names or deciding who to promote. Before you go ahead with implementation, make sure the decision are yours and when things don’t go well, make sure that you stand by them for these decisions and take ownership; just like you support your code when it has issues. If these decisions are being imposed on you, speak your mind and express your concerns; in a civilized yet very open and completely blatant fashion.

Long winded meetings where even the junior most person in the room knows the stupidity of the suggestions being proposed and the correct solution to the problem; but no-one in the meeting brings the correct solutions out in the open, blatantly and honestly as everyone goes round and round sugar coating the issue, are fairly common in most corporate environments.

If you work for a software development firm, look around you and ask yourself a few simple questions about the people you can see or think about:

1. How many them are capable of speaking their mind, even with their bosses sitting in the room?
2. How many of them are capable of speaking their mind even at the risk of getting fired?
3. How many of them are capable of giving you their blatantly honest opinions?
4. How many of them are capable of breaking any bad news to you by looking at you in the eye?
5. How many of them have a clear succession plan prepared for the day they are fired or quit?
6. How many of them aren’t afraid to discuss this succession plan openly without any insecurities what-so-ever?

I could go on with the list, but the primary million dollar question I’m trying to ask is simple: how many of them have a strong spine?

If you can name a huge number of individuals who do, chances are you are in an organization that’ll survive the hostile attacks of bad times. If not, chances are, you’re headed for trouble and when trouble strikes, you won’t even know because everyone you’re looking at or thinking about right now, will either be busy sugar coating things or indulging themselves in a CYA exercise.

The software development word is going round and round in the infinite loop of failure; Managers and Developers with a strong spine are desperately needed in the software development world. How many do these individuals you know? How many of them work with you? How many of them are in your team?

When you hire, do you make a conscious effort to hire people with stronger spines? When you have hired them successfully do you even appreciate them and give them the due credit they deserve? Next time you’re hiring, don’t just check their technical competence, education qualifications and their IQ level before get them in. Follow your intuitions about the people you hire and try to figure out how strong their spines are before you go ahead and bring them onboard.

When one of your job role includes managing working with a team it is best for you and everyone you work with, if you to have a very short memory.

This post now has a picture and I’ve said what I wanted to say. I’m done. Post over. Thank you for reading. You can close your browser window now. 

-------

Hey wait!

That was a joke you idiot!

You weren’t closing that browser or that aggregator window, were you?

Seriously!

This post is far from over. You know the part where I sell my idea to you even if you aren’t willing to buy it at first shot? That part is still left. Read on, dear reader. Read on and help me help you get convinced that having a short memory, is an asset for you; particularly, If you are a project manager, or in any way responsible for leading a team.

To prove my point, I’m going to talk about perception, stickiness, arguments, shit and finally bring everything together to help you see things from my perspective. Humor me dear reader. I have a point to make. At-least I think I do.

Perception:

Human beings are animals working on perception. Andrew Hunt and David Thomas in their book ‘The Pragmatic Programmer: From Journeyman to Master’ describe the power of perception:

We've never tried this—honest. But they say that if you take a frog and drop it into boiling water, it will jump straight back out again. However, if you place the frog in a pan of cold water, then gradually heat it, the frog won't notice the slow increase in temperature and will stay put until cooked.

Perception is powerful. In a project running at Multiplitaxion Inc, the team made a terrible mistake. When their team lead picked an invalid underlying framework which was built to support resume driven development in the first place, no one in the team argued back.

Needless to say, the project burnt-out very soon and the team was taking way too much time to implement each feature as they struggled with each build push cycle. They were staying late, working hard, making ends meet and struggling. They had played really hard working nice guys but had lost the battle way before it had begun.

They had failed. But that was not their biggest mistake. More than a failed project, they had created for themselves, a sudden jerk of unhealthy perception. They had thrown the management in the bowl of boiling water and they had done it suddenly.

Stickiness:

As human beings we don’t tend to judge other human beings holistically. We either see their good side or their bad side. We either glorify individuals or we demonize them. Have you every been in ‘resource review meetings’ of even some of the best organizations on this planet? ‘He is good’, ‘she is bad’, ‘he is average’ – statements like these, and individuals being labeled as ‘good’, ‘average’ or ‘bad’ is a common practice in our industry.

In most organizations, the perception of failure or the label with the word ‘bad’ has even a larger problem associated with it: it’s sticky.

On a side note, remember that boy who was in kindergarten with you and was punished for naughtiness regularly back then? He was the naughtiest brat in school all the way till high school wasn’t he?

Look at your ‘resource report’ and go look at that guy who had failed in a couple of projects when he joined the organization. Chances are, he is well on his way to yet another failed project.  Doesn’t that sound awfully similar to that brat in kindergarten who remained a brat all the way till high-school?

The perception of failure is indeed sticky.

Arguments:

This one really deserves a post by itself; but the fact is, that if you have a decently smart team from varied background, cultures and pasts they are going to be highly opinionated. They are not going to be afraid starting a fight with you; argue with you; drive you nuts and even make you feel like firing them.

Shit:

Here’s a small part of things I’ve seen happening in my career spanning over years spent in a few organization. Even though these are incidents that have happened in different organizations, cultures and countries they have one common theme which we shall get to soon. Here’s a part of the list of incidents:

1. A particular individual was stealing Office supplies and RAM from the office hardware and ultimately ended up getting caught.
2. A particular individual was billing the client for his groceries and videos. 
3. A particular individual got into a heated mail argument over Java vs. .NET for no particular reason.

I could go on with the list forever but I’m sure if you were reading carefully you may have noticed the common theme amongst these incidents. These incidents were all shitty; but the individuals involved in those incidents weren’t anywhere close to being shitty. I leave you with words of wisdom from Forest Gump – 'Shit Happens'.

Connecting The Dots:

Perception is powerful. Besides being a manager you are one-hundred percent human and chances are that perception is going to have a huge impact on you. You team is going to fail all the time; failure is going to have some stickiness associated with it; People are going to argue with you and make you feel like you really need to fire them; and shit, well that’s just bound to happen all the time.

Where am I trying to go with this?

All I am trying to do is tell you dear reader, that maybe, just maybe, that naughty little guy who was a brat in kindergarten, remained a brat all the way till high school because when he moved from one class to another teachers exchanged feedback and every teacher that followed had a very sharp memory.

In simple words, dear reader, the point I am trying to make here, is that if you lead a project or work with a team, maybe, just maybe, you would be better off having a short memory and wiping the slate clean once or twice for our colleagues. Overcoming bad perceptions, letting go of stickiness associated with failures, dealing with arguments and cleaning up shit is not easy; but then, when I started this post, I never said I was going to tell you that creating an environment where successful teams can blossom is easy. All I said was that I would talk about the virtues of a short memory; and I did.

I’m an idiot with a thick skin and a very short memory; and I’m proud of that. Are you?

If you are managing working with a team consider criticism with empathy and help them when they make mistakes. Once their mistakes are history, consider forgetfulness and wipe their slate clean once in a while.

Ok, now I’m done.

Thank you for reading.

Post over. You can close that browser or that aggregator window now.