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.

During his very early days as a manager for a brief period of time, Pops wrote fairly heated emails to people in his team when they indulged in the acts of incompetence.  Very soon, he realized that those heated emails were creating one consistent output: More Incompetence. That added incompetence of course resulted in more heated emails being sent by Pops. This thing was almost like the infinite loop of failure.

As I watched the productivity of my team go down I felt awfully sorry and completely responsible for that productivity drop. I had always loved computers and working in a team but for a brief period of time I had violated the fundamental rule of good teamwork and leadership. Instead of criticizing myself first, I had criticized others and had almost taken the first step towards hiding behind the excuse of their incompetency. As an effect, I had made the workplace a little less fun for others; and that in any developer’s or manager’s work-life, is the equivalent of a criminal offence.

One of my first organization happened to be a place where when a project failed, we had an open meeting involving all team members. This was an occasion where everyone indulged in CYA exercise, followed by a blatantly open finger pointing exercise and someone would be fired. Having seen a culture like that when I jumped over to a different organization, I had resolved to myself that I would appreciate human beings and grab every opportunity to create a healthier environment everywhere I went and whenever I could.

For a brief period of a couple of months I forgot that resolve and committed the stupid mistake of ruthless criticism. Then almost with a sudden flash of light, I remembered how it felt to be on the receiving side of this criticism. My strange experiences from those firing meetings and my past organization to an extent rescued me from falling in the pit of prickdom right in time.

Since then I’ve seen almost magical changes and examples of incompetence change to core competency more than once. I’ve seen individuals on the verge of being fired by managers turn to one of the most critical team members by a mere change of role, by simple acts of encouragement or a little bit of honest support.

For me I learnt this lesson the hard way though; it took difficult experiences in my past organization and some soul searching followed by sudden realization to finally help me understand. I was lucky to have been through this learning experience in a very short span of time.

Having said that, however, this post, doesn’t end with Pops living happily ever after. After all, dear reader, as much as you might like this blog, I do realize perfectly well that you don’t care about me or my past. This post, of course has more to it than just a little story from my lousy past.

Years later, even today, I see countless managers with years of experience behind them, conveniently indulge in act of shattering criticism, sending flame mails, hiding behind the excuse of their team’s incompetence, putting in no genuine effort of fixing the core problem and spending no or very little effort to genuinely help their team.

In fact, it almost seems like a fashion statement to announce glamorously, that putting in effort to help and mentor incompetence, even if there is a possibility of being able to fix things easily, by the use of simple motivation, guidance or change of role, is not worth a good manager’s time.

John Maeda in his post about being the good boss hits the nail right on it’s head. He explains:

When a team succeeds at achieving a lofty goal, the good boss credits her team members as being the reasons for success instead of herself. This "boss behavior" enables the team to trust their boss as one who enables their own careers over the boss' own career. When a team fails at achieving a lofty goal, the good boss owns the failure as her own and doesn't blame the team. This boss behavior enables the team members to take creative risks with their work, and not feel they will be penalized by their boss when/if they fail. Both boss behaviors require the core attributes of the boss as: 1) being self-assured but not an *sshole about it, 2) keeping the larger goals in mind with priority over the issues that are just local to herself, and 3) facing each day with acceptance of the challenging responsibilities that comes with being the boss.

It’s a well laid out post, which comes straight to the point; but just in case you weren’t reading between the lines, let’s simplify this for you:

If you lead a team and the team fails, it’s ‘your’ fault. You’re supposed to accept that, and take all the blame for the failure on yourself. Simple.

Most managers in our business find simplicity at that level scary. Almost all of them find it difficult to digest the idea that when you’re leading, CYA is not an option. This is precisely why failure postmortems and root-cause-analysis for failed projects are so common in our industry. Scott Berkun describes how most managers suck at the basics:

In management / design / business circles I know for certain of one reason. Flat out hubris. For an executive to say: “This project sucks because I have failed to organize this team effectively”requires a huge amount of humility. Much more humility than is required to say something like “Our innovation infrastructure needs to be redistributed to support the new rate of change”. Or some other bullshit that sounds complex, makes him seem smart, and entirely distracts people away from what might solve the problem: identifying the problem in the simplest terms possible.

In the world of software development most managers are taught the blame game, right when they are young and budding management students, business analysts or programmers taking their first fumbling steps at managing a team. For most managers, blaming the process, an individual’s incompetence or the whole team’s incompetence is an easy excuse for all failures; including theirs. I’ve hardly ever seen managers personally attached to team members, spending genuine effort in trying to help them find their core competencies and coming forward to blatantly own up failures and take responsibility when things don’t work out.

I’ve hardly ever seen managers lending constructive one on one direct verbal criticism followed by genuine help. I’m not talking about a generalized you-need-to-get-better-at-coding-email followed by be-careful-next-time-email followed by I-am-going-home-but-check-in-the-code-and-email-me-the-status-as-soon-as-possible kind of criticism here.

I’m talking about the blatant and precise your-use-of-object-orientation-in-the-administration-module-sucks said with empathy, followed by a joke, followed by lets-go-out-for-a-cup-of-coffee, followed by lets-stay-late-and-refractor-together kind of constructive criticism. Or for that matter, let’s-meet-during-the-weekend-and-fix-this kind of constructive criticism; and that dear reader, irrespective of what they tell you, is not a waste of your time; it’s what you were hired to do; especially If you were hired to lead a team. If you weren’t specifically hired to do that, I suggest that you do it anyways.

If you work with a team, don’t criticize ruthlessly; if you lead a team don’t play the blame game; and remember, it doesn’t matter what they teach you in management schools or tell you at your workplace, if your project isn’t cruising along successfully, it’s always your fault.

If you must criticize, do so constructively, followed by empathy, followed by genuine help. I can’t teach you how to do that. What I can do, however, dear reader, is end this post abruptly and rather dramatically, leaving you with words of wisdom worth pondering on, from one of my all time favorite movies. Here’s Wishing you, good leadership, healthy teams and a good life.

In one of my earlier posts I basically advised that team members liking each other is the secret sauce of successful teams. Hand picking team members and creating a culture that is open, transparent and where most team members like and truly respect each other is a dream come true for most managers consulting around the planet. In reality most of us have to move from one client to another or one organization to another as we consult and work with multiple teams and deliver projects or products.

If you lead work with a team, and if you’re not as lucky as I was thrice in my career, chances are that you probably inherited a part of or the whole of your team from their previous manager when you joined your organization.

When I first worked with an inherited team at Multiplitaxion Inc, I realized how different it is from hand-picking every single individual in your team based on your core values and your very own selection criteria. Internal frictions, ego issues and complexities within the team were way too high to get anything done.  It almost felt like having walked into a fifth grade class room with students fighting with each other.

While it is tempting to setup a strong hierarchy of rules, Jurgen Appelo in his post Real Agile Teams can Flocking, makes a valid point that Agile Development is more about setting constraints than it is about setting rules. He explains:

People often try to solve problems by introducing rules in an organization, in the form of "When situation X occurs again, you must do Y." I admit that I am sometimes guilty of such behavior myself, though I am convinced that it is not the best approach. It is better to leave rule selection to individual team members, and instead focus on imposing the proper constraints. Agile software development should be about setting constraints, not rules. It has been discovered that the flocking of birds can easily be modeled on a computer. This behavior, which is also apparent in many other kinds of animals, emerges through the application of a few very simple constraints: Don't leave the group; Don't bump into each other; Fly in the same direction. Specific implementations of these constraints are often used in the movie industry to create computer animated birds, bats, fish, penguins, you name it.

Jurgeon believes that modeling flocking of birds on a computer is much harder when done through a set of if-then rules than it is done by constraints and so is setting up an organization or a team. According to Jurgeon, it’s not about rules, it’s about the constraints:

It's Not About Rules, It's About Constraints The mistake people often make is that they directly try to "program" team members by giving them rules to follow. "IF you receive this type of document THEN you must perform that activity," and "IF the customer wants some new requirement THEN you must start this-or-that procedure." But the power of complex systems is that agents can manage their own rule selection process. People must restrict themselves to setting constraints, and then allow team members to solve their own problems. Agile software development is the natural approach to manage software projects. It sets constraints like "collaborate with the customer", "allow frequent changes" and "only deliver stuff that works". And then it's up to the team to select and implement rules like "IF the customer cannot travel THEN we do our demo using Skype," or "IF there's change request THEN we create a new branch in source control," and "IF someone breaks the build THEN he must wear the funny rabbit ears."

It’s rare to find teams you genuinely and truly like working with; so much so that you see them as a part of your life rather than just colleagues. In order to land up with a team like that stars have to align and you genuinely have to be really lucky. If you’re not that lucky however, or if you’ve inherited a team that has a little bit of friction, don’t lose heart. Setup the basic constraints in place first; then give the team the basic freedom, flexibility and trust to form their own rules. Chances are that things might work out.

Who knows, you might even end up finding a few colleagues you genuinely start liking to work with over time. While Jurgeon, in his post, re-words the constraints for agile teams and considers them slightly different from the constraints of a flock of birds, I personally think the that original constraints for the flock of birds work for Agile teams as well. Team dynamics are stupid simple, you don’t exactly require the IQ of a genius to get it. You can literally be as half witted as a humming bird and still get it all right. The only thing you have to know well is flocking together.

Remember; Don’t Leave the group. Don’t bump into each other. Fly in the same direction.

Everything else, including all your process and rules, is just details.

Flock on people. Flock on.

My stand on Project Plans and Microsoft Project Files in particular makes me sound like a person who does not believe in planning. More than one individual found my post on project plans; more specifically my ideas on this topic controversial and threw a few punches at me on the topic while we got into a heated debate comparing Agile with some other big design up front methodologies when it came monitoring a project status. My point however, was that the debate didn’t weigh both methodologies objectively.

While Big Design Upfront methodologies like Waterfall, focus on tracking the project status, light weight methodologies are more about tracking the project’s progress. Weighing both of them on the same scale doesn’t seem to make sense. The argument presented was somewhat on the lines of:

See when you compare quality in Agile Projects vs. Quality in CMM or RUP projects the quality of CMM and RUP projects is much higher purely because during all this time Agile hasn’t even been able to come up with one decent standard to measure project status.

The fundamental realm of Agile turns out to be slightly different. Measuring the project status in terms of percentage has never been the strong hold of agile methodologies like scrum. Having said that if you’ve never used agile before and are curious about ways to track your projects ‘health’ and progress using agile, multiple ways exist. Burn down chart happens to be just one of them. Wikipedia does a lousy job at giving details about burn down charts:

A burn down chart is graphical representation of work left to do vs. time. The outstanding work (or backlog) is often on the vertical axis, with time along the horizontal. It is useful for predicting when all of the work will be completed. It is often used in Agile software development methodologies such as Scrum.

With a methodology like scrum you want to monitor progress of:

1. Your current sprint.
2. Your current release.
3. Your final product.

Deciding the definition of done is fundamental to the success of any scrum project. Once you have frozen on the definition of what defines a feature as ‘done’ or ‘complete’ you would typically start by listing out your use-cases, user-stories or plain old features and sub-features.

A typical scrum project that you work on would generally consist of work items in the form of these use-cases, user-stories or plain old features and sub-features. Now if you were to plot point of features ‘remaining’ to be done on the Y-axis and the number of days on the X-axis and you were to get that done every single day of your project you would have something that would look like this:

And that my dear readers, is a simple burn down chart.

Going by the basic concept the burn down chart is a rather simple idea which has more to do with ‘wisdom’ than it has to do with knowledge of how to build it. Just like I’ve gone ahead and drawn the burn-down chart for a sprint, you could do it for a release and call it your release burndown. Learning how to draw burn-down charts is a matter of acquiring information which is rather easy to acquire but analyzing your burn-down charts is art of wisdom, not just knowledge of the data and how to transform it into a burn down chart.

If you keep monitoring your burn down chart sprint after sprint and release after release you will realize that you team, has a finite and well defined velocity. Trying to ‘push and pressure’ your team to ship faster than their natural velocity can be suicidal. Let’s monitor a team at Multiplitaxion Inc, who, with their natural velocity, have a burn down chart that looks somewhat like this:

On a side note, burndown charts in real time are hardly ever a straight line, but that’s not the point. Humor me. I have a different point to make and the actual shape of the burndown chart hardly matters.

The management at Multiplitaxion Inc, aren’t really happy with this velocity because the competition is catching up faster; so they panic, pressuring the development team to push harder. Given the team leader’s highly complying nature and optimism he agrees and the team starts to work ‘really hard’. They create a little bit of code litter and add a little bit of a code smell, break a few good practices and ship faster. The code ships and the burn-down chart, compared to the one with their natural velocity, looks much like:

Now if you are a young and budding project manager you’re thinking:

Hey Pops, The management is happy, the team is happy and the sky is blue with the sun shinning brightly. The development team took their butts off their chairs, stopped playing video games and worked harder. So what? After all no-one was killed. In fact people got praises and promotions for successful implementation.

That’s perfect. Right?

Wrong.

The sprint ends up being what I refer to as a ‘successful failure’. This example is a classic example of the first window being broken and the broken window theory kick in.

The next sprint, the team needs time to clean the code litter they created, but the competition is catching up, the team lead is acting like a prick and pushing them harder. Now even their old natural velocity isn’t enough to clean up the litter done in the previous sprint and reach the feature complete mark in the given time. They ‘work harder’, create more litter and soon the broken window theory starts to become prominent.

The next sprint takes a little more time only to result in a little more pressure from the management followed by some more litter to seed up the development in the following sprint.

Over a period of time, the code becomes complex to maintain and extend. Features start taking more time to build and the pressure from the business just keeps mounting up. Sprint after sprint more litter is introduced in the code base and the code keeps getting more and more complex. Iteration after Iteration the burndown charts start looking somewhat like:

This continues till someone realizes that features are taking too much time to build, it doesn’t even make sense continue to the project and pulls the plug.  If you’ve witnessed projects being shut down because development of features was taking too much time the above chart in action is exactly what you’ve witnessed.

Once you get a general idea of your team’s velocity and can ‘see’ it on a burndown chart, keep a close eye on the burndown sprint after sprint. If you see you burndown chart becoming unexpected steeper it doesn’t always mean your team is ‘working harder’. In fact, every time you see the burndown chart going any steeper than the team’s natural velocity you need to stop and ask yourself the following questions: 

1. Has the team moved to a radical and more efficient technology?
2. Have more efficient team members have joined your team?
3. Have the features that are being built become blatantly simpler because of change in requirements?

Net-Net you need to keep questioning till you can find a way explains the sudden steepness. If you can’t, the same team usually does not become much more efficient overnight and the steepness might be an indication of people panicking and the broken window theory being kicked off in practice.

Periodic glances on burn down chart are much better than policing your teams with a Gantt Chart. Monitor your burndown charts every now and then and every time they sway on either side, coordinate better.