Years ago, I find myself working for a huge Texas based client of ours. I have slowly and gradually become one of the star performers in a team of three. For reasons beyond my understanding, it is often being assumed that I am of French (or some other) origin.

It is somewhere bang in the middle of the project that a SOS request for help comes in from a connected project team that is working out of the same campus. When Fred walks up to a couple of other guys and me, seeking help with fixing and refactoring code he is rather articulate about how the code got this convoluted in the first place. He explains - 'They got some Indians to write this. Those Indian guys f@#cked it up. What else could you expect?'

I smile inwardly.

After spending some time, we have white boarded a solution and I find Fred thanking us for all our help in fixing the code. Without further adieu I decide to disclose my true identity using a friendly joke cracked with a simple as-a-matter-of-fact smile: 'So, the code that was fu@#ked up by a stupid Indian was fixed by another stupid Indian'. 

I stand there smiling while Fred experiences a long awkward silence as the news of my being an Indian slowly sinks into his head.

Fred apologies. Suddenly he acts like I have caught him scoring a foul.

I crack a joke about me knowing exactly how it feels to work with Indians. That lightens the situation instantly.

Then we talk about whether and movies. Soon life returns back to normal.

Years later I find myself writing about the incident and adding my very own fictional elements to it.

If you have been in the business of building software long enough and have worked in more than a couple of countries, chances are, that you might have pre-conceived notions and stereotypes about people from different countries.

Chimamanda Adichie describes the issues with this kind stereotyping in her TED talk on the danger of a single story. She explains:

Years later I thought about this when I left Nigeria to go a university, in the United States.

I was nineteen. My American roommate was shocked by me. She asked where I had learnt to speak English so well and was confused when I said that Nigeria happens to have English as its official language.

She asked if she could listen to what she called my 'tribal music' and was consequently very disappointed when I produced my tape of Mariah Carrey.

She assumed that I did not know how to use to a stove. What struck me was this - she had felt sorry for me even before she saw me; had a default position towards me as an African, was a kind of patronizing, well-meaning pity.

My roommate had a single story of Africa - A Single story of catastrophe. In this story there was no possibility of Africans being similar to her in any way. No possibility of feelings more complex than pity. No possibility of a connection as human equals.

The single story creates stereotypes and the problem with stereotypes is not that they are untrue but that they are incomplete. They make one story become the only story.

In my career, I have worked with people from Pakistan, Germany, England, Sri-Lanka and the US. If there is one thing I have learnt about people from different countries around the world, it is that smart people exist in every nook-and-corner of the world.

My approach towards classifying human beings is pretty similar thought approach Nassim Nicholas Taleb takes in his book The Black Swan. In his famous book, the black swan, Nassim describes his thought process on this topic. He explains:

This nationality business helps you make a great story and satisfies your hunger for ascription of causes.

It seems to be the dump site where all explanations go until one can ferret out a more obvious one (such as, say, some evolutionary argument that "makes sense").

Indeed, people tend to fool themselves with their self-narrative of "national identity," which, in a breakthrough paper in Science by sixty-five authors, was shown to be a total fiction.

("National traits" might be great for movies, they might help a lot with war, but they are Platonic notions that carry no empirical validity—yet, for example, both the English and the non-English erroneously believe in an English "national temperament.")

Empirically, sex, social class, and profession seem to be better predictors of someone's behavior than nationality (a male from Sweden resembles a male from Togo more than a female from Sweden; a philosopher from Peru resembles a philosopher from Scotland more than a janitor from Peru; and so on).

This post, dear reader, is not so much about an isolated incident of my life, or stereotypes connected with my being an Indian. This post, dear reader, is my humble attempt at gently nudging you, dear reader, to avoid all stereotypes in your life, as far as you can.

Software developers are not very good at communication.

Geeks are usually not into fitness or fashion.

All Indians are cheap bodies who write shitty code and suck at communication.

As programmers, we are surrounded by hundreds of these stereotypes and what I intend to do with this series of posts, is to blow up some of these stereotypes, expose exceptions, and bring to your notice, the fact that multiple sides of the story can exist.

Now, what I want you to do, dear reader, is to go out there, every once in a while, pick up any of of these stereotypes, challenge it and find out the truth for yourself. For it is only by challenging some of these stereotypes that you will find truly remarkable people, stories and results.

I wish you good luck.

Jack is at my desk; talking about how he deserves an additional seven percent salary hike over and above what his next month's appraisal promises him. He even has an offer letter from a different company to show me what his 'market value' is. It truly is just seven percent more than what Multiplitaxion Inc would have promised him in the next appraisal.

Jack really 'needs' that seven percent and he needs the seven percent now. He even has an offer letter to prove to me that he means business.

I file a request for a 'match' and escalate the request to what is often referred to as 'upper management'.

I am happy because I know the request might get accepted.

At the same time however; I feel deeply sorry for Jack deep down inside; because Jack just used his trump card for a measly seven percent salary hike.

For the first couple of years that you spend in an organization; you are basically warming up and developing deeper roots within the organization. You are understanding the culture chart of the organization; understanding what it will take to bring about changes. It is after these couple of years; that you wake up one fine morning and find out that people are listening to what you have to say.

This is when you start loving your organization and your organization starts loving you back.

Attached with this love is also the fear element of this relationship coming to an end. Your organization has a fear of losing you; and you dear; reader have a fear of losing your organization. 

This is when; you start realizing that people in your team and at times even folks in other teams are listening to you or looking up to you for help or advice. This is when you start making small changes to the organization.

Word of advice if you are going through this phase of your life: Slow down. Be careful.

This is by far the riskiest time of your career. This is when you learn that you as a young; budding and a rather valuable engineer have a trump card you can use.

Your resignation.

You know that it will send ripples down the organizational pond. This is when you will be tempted to do crazy things - like negotiate a seven percent hike on your salary based on offers from another organization.

Now here is another word of advice if you have been reading along and have been thinking of using your trump card: Don't.

The use of the trump card passes valuable information over to your organization. This is the kind of stuff folks people who run companies for instance; are on the look out for:

What drives you.

Your using the trump card for a simple salary percentage hike says out loud that the number on your paycheck drives you. I don't know about you; but if I was running a startup; I would be a little uncomfortable putting up with someone who is solely driven by the numbers on his paycheck so much so that he can quit for a seven percent salary hike.

What would it take to retain you.

You know the whole thing about love relationships that make them so desirable; it is the mystery of it. It involves working hard to getting to know the other person; spending time with the other person and learning what the other person really wants or does not want.

Now; all of this also applies to retention of employee. Your quitting for a small percentage of salary hike; yells out loud that retaining you in the organization is as easy as retaining a piece of furniture that can be bought from a local furniture store.

What are the changes that you can bring about.

Most organizations and entrepreneurs tend to look for leadership in people they want to promote and retain in the long term. Most entrepreneurs also realize that they need this leadership to spread their shared vision and to correct them if they start making mistakes or walking in the wrong direction.

If all that worries you every appraisal cycle is a seven percent salary hike for yourself; I personally; would not see you as someone who can be what I call a 'partner in crime'. An excellent employee; maybe; but not someone who can share a vision and work for the organization like it truly belongs to him.

With years spent in the organization; you get a truck load of responsibilities and a trump card that you; at all time; should try your best; not to use.

Remember; the lesser you use the trump card; the better off you will be.

And now; a final word of advice: forget that the trump card exist; and get back to work. If you continue using your trump card; chances are that things will never work out and you might never really exactly get what you wanted; but if you stop using it; forget that it exists; and focus on working towards growth; chances are that things might work out in the long run.

I wish you good luck.

At Multiplitaxion Inc; people are optimistic about everything that they do. Jack; a programmer sitting across in his is silently and quietly celebrating the fact that the organization has signed up a new project. My problem; dear reader; is my knowing that we do not have a sign off from a client yet.

How did he learn about the new client; I ask him hesitantly.

His manager told him; I am told.

I cringe; then I decide to keep my gob shut.

As someone who leads teams of programmers there is something you need to know about both good-news and bad-news. They spread; within the corridors of the organization. They spread in an uncontrolled manner; pretty much like an organizational wild fire that is rather painful to stop once it starts spreading.

To add to that; most managers that I have seen around the globe seem to have another problem. It is a problem with transmission of messages. Messages often change drastically when they move from managers to programmers.

A classic example for instance is: we 'might' sign off a really huge project next week becomes we 'will' sign off a really huge project next week.

What this means is that getting Jack in a room and telling him about a new deal that Multiplitaxion Inc 'might' sign off; will often mean that you end up telling him about a new deal Multiplitaxion Inc 'will' sign off.

When you do that as a manager what you are doing is adding a lethal dose of optimism and starting a wildfire. If you are one lucky son of a gun; the sign off will happen next week and the wildfire of happiness you started will do no harm.

If however; you are like most of us mere mortals; in most cases Murphy's Law will kick in; which simply put; means that if something can go wrong; it will. It is then; that you might find yourself indulging in a painful firefighting exercise.

Spread wildfires of happiness with optimism a couple of times and you have lost all confidence that people who work with you had in you.

As individuals who lead a team and as human beings in general; we crave to become the bearer of good news.

Obviously you love spreading Happy wildfires; but before you do; think.

Are you adding unnecessary elements of optimism to these happy wildfires? Are you creating happy wildfires which you might have to bring to painful a painful halt in future? Are your happy wildfire based on genuine confirmed good-news or are there elements of your personal wishful thinking?

If your good news has elements of personal optimism and wishful thinking attached to it; you be better off waiting a while before you light the wildfire. Hold off lighting the fire till you have a confirmation of good news and till you know deep down inside that there are no elements of personal optimism and wishful thinking involved in lighting the wildfire of happiness.

I wish you good luck.

Optimism. It is that thing that will sneak up from behind and will take your project down. No; Seriously. It is the thing that makes you believe that they care about what you are building. It is also what will make you believe that your idea or product rocks. That it will 'change the way people do business'.

Newsflash: No one cares about your product.

Second Newsflash: Your idea probably is not as good as you think you it is.

Third Newsflash: Your product will probably launch and perish like a slightly different low budget Hollywood movie that never made it to the big screens.

I have seen over a dozen software products take a nose-dive Microsoft Bob style - every single one with a single unifying theme tying the failure.

The director; vice-president; or someone high up in the pecking order; usually misses out on asking a simple question - What if you build it; flawlessly and the audience of millions you expected decides that it just does not want to show up; or what if the audience of one that you expect to pay for the product decides that the product idea itself is just not good enough to pay anything for?

If you are knitting your brow and wondering why I sound pessimistic and why that might happen to your product website or your product even when you pour your heart and long hours implementing an idea that you considered to be seriously kick-ass innovation of the year; allow me dear reader; to present my thought process to you with simple mathematical figures:

In one of the citations I read a couple of years ago; the average number of users for any given site on planet earth was quoted as two users. The numbers since then have increased substantially but the overall equation remains just as bad.

Number of websites on planet earth: 156,000,000

Number of people internet users: 1670000000

This dear reader; leaves you with around eleven users on your product website; system or blog. Build a website or a product that is 'decently good' or mediocre and an average traffic of eleven users is all you should expect.

For anything more than eleven you might have to move away from the realms of mediocrity and build something that is genuinely remarkable or helps people; not something that you 'think' is remarkable and definitely not just something that you 'think' will help people.

Go slow. Take small steps. Wrap up projects that are not going anywhere. Continue things that are working and push them harder.

Building mediocre products is just not an option; because mediocre products result in mediocre traffic and mediocre traffic of eleven users; on the software development world of today is so-not-exciting.

Now go build something that gets more than returning eleven users.

I wish you good luck.

Fred approaches my office with heavy steps and a question that often makes me cringe. I have done the whole motivating; playing the father; explaining; mentoring part with Fred a thousand times before and yet the question remains - 'when is my project ending so that I can be placed on a new project'.

The answer makes a slow entry into my mind as I contemplate on if I should be breaking the bad news to Fred yet --- "Never. Hopefully." --- I hear a voice deep down in my mind respond to that question.

If you go by the paradigm - everything you do is a project  - I am not so sure I agree to Fred or for that matter Tom Mochal's idea of completing a project as quickly as you can. Tom; in his story about how he put a never ending project to end; sounds very typical of how most project managers or developers think about and react to long running projects. He documents his very own personal experience:

“Terry,” I began. “What’s going on? Your project is lasting much longer than anticipated, yet I don’t see or hear any indication that you are behind schedule.”

“There have been a number of scope changes that have required us to push the end date out,” Terry said. “However, you will be glad to know that I am invoking scope-change management. Each change is being approved by our sponsor, so we have been getting extra funding and extensions on our deadline.”

“That explains why no one is complaining,” I noted. “What types of change requests are you receiving?”

“They are mostly for additional features and functions, and small changes to our current deliverables,” she said. “That’s one reason why we have been able to accommodate most of them successfully. They don’t require a lot of work from our team.”

“What’s the future look like?” I asked. “Are you going to be able to complete the project in four weeks?”

“It’s not clear,” she replied a bit apprehensively. “Most of the shop floor supervisors have never had extensive Web experience. Now that they are getting more familiar with that environment, they are finding more and more features they want to incorporate.”

“Well, that’s not entirely good,” I said. “Projects are temporary endeavors to produce a set of deliverables. They need to come to an end at some point. I’m afraid you may be in a position where your project goes on and on, with minor changes bringing incremental and marginal business value.”

Terry agreed. “In fact, I think the team is starting to lose focus and energy. I have some concerns that we're getting a little sloppy.”

“Let’s talk with your sponsor about bringing the project to a close,” I suggested. “This doesn’t mean they have no chance for additional changes. If there is business value in additional modifications, let’s consider them enhancements for the future.” 

What Tom fundamentally misses out on; is that successful projects; often never really end. Sprints end. Versions do; too. But not the projects themselves. Any programmer worth his salt who has worked on a product that has stood the test of time and has survived for more than a couple of versions will tell you this.

Linux. Windows. JBoss. Microsoft Office. Go ahead. Pick any successful piece of software out there and ask their parent organizations when they plan on putting a stop to it.

You think that is a stupid idea?

Thought so.

Seriously; that is the whole point of writing code that you can support for years; growing your code organically and keeping it clean for years as you morph slowly over to new technology stacks and churn out new versions that do more; work faster and get better; year after year.

As developers and even as managers; we have this yearning desire to 'start fresh' every once in a while.

A desire to end your project and jump over to another one; often indicates a project badly implemented project in the first place.

The next time you get on a project; dear reader; may I suggest that you work under the basic assumption that your project is not going to end anytime soon and that you are going to be supporting what you write for multiple years to come.

That thought process; dear reader; might be your only chance against the temptation of creating a mess and then jumping over to something else; while someone else does a clean up of the mess you created.

Remember; as you write your code; work under the assumption that you are going to be stuck with your current project for life. Is your code maintainable? Easy to migrate part-by-part when new versions of the underlying technology stacks show up? If your code extendable? Is your code going to not just stay alive but thrive for the years to come?

If yes; you are going to love working in a never-ending project. If not; you might want to start by assuming that you are not leaving the project anytime soon; settle down; and start doing something about the mess that you just created.

I wish you good luck.

On a bright sunny morning I find myself talking to a very smart acquaintance. The conversation revolves around how human beings in general and programmers in particular grow in their professional life.

He describes his mentoring approach using circles; where the green circle indicates your comfort zone and the red one indicates what your new assignment needs you to do.

His contention is that most managers encourage their employees do get involved with new assignments which are somewhat on these lines:

Put simply; with every new project; you are doing most of what you did in your last project and then you learn something new.

His approach to mentoring is simple; move the circles as far away from each other as practically possible; move people out of their comfort zone and see if they pull it off or breakdown and collapse.

I am myself a strong believer of getting out of your comfort zone. I have even suggested that developers should in fact bring themselves dangerously close to getting fired each year.

Having said that; I am not so sure if the approach is a universal solution to helping people grow.

Havi Brooks; for example; has a slightly different take on making people leave their comfort zone and presenting them with wild and scary challenges which make them collapse. She explains:

I can’t even tell you how many eager beaver coaches I meet at business events who can’t wait to meet people just like you, so they can drag you kicking and screaming from your comfort zone. They think they’re doing you a favor. They’re not.

They’re not doing it out of meanness, of course. They sincerely want to help. They think that if you can leave the place where you’re comfortable and try this new, scary thing, you’ll get over it already. The problem is that sometimes what you need in order to grow is more comfort. And this kind of work needs to happen where you feel safe; where you’re most comfortable.

That’s why there’s a zone for it.

In the future your grandchildren will look back on this age of insisting on people leaving their comfort zones with shock, horror and a sad shake of the head. The way we do now when we think about things like electric shock therapy and lobotomies. The atrocities of good intentions.

Instead of leaving your comfort zone, let it grow with you

Stretching is good. Gently. Learning new skills is good. Gradually.

Learning new things doesn’t have to mean leaving the comfort zone. You actually want to be growing your comfort zone. And you can do it with as much comfort as possible. At a pace and speed that are comfortable, with support from people who adore you, and adding tricks and techniques as you go.

Your comfort zone is your friend. So you have my permission to stop trying to break your way out of it and start trying to cultivate it, nourish it, grow it and be nice to it. Hey, I’m waving to you from mine — squeaky duck in hand — right now.

To be honest; I don’t have all the answers here. Each human being is different and while a hard push out of their comfort zone followed by a what-does-not-kill-you-makes-you-stronger approach might do wonders for some; some of your best developers might actually grow the fastest with a series of really gentle nudges where they are allowed to slowly and steadily increase the size of their comfort zone.

Maybe it is not about jumping out of your comfort zone; maybe it is just being on the edge of it all the time and then pushing it a little farther each time you can.

I cannot tell you if you should jump out of your comfort zone all together in an attempt to make yourself stronger or slowly grow your comfort zone every in a gradual step by step approach. If you think about it; both are 'technically' just different ways to 'grow' your comfort zone. One with hard jerks and push; the other with constant, consistent persistence.

Even though; given the choice; I might tend to lean more towards the brook's approach for the people who work with me; I am not here; dear reader; to advice you on which one of the two approaches you should take for your very own personal growth as a programmer.

What works best for you; in this case; is for you to find out yourself.

What I can tell you; however; is that even if your comfort zone is growing by a tiny-little-bit every single day of your life; and I seriously do not care what is making it grow - a hard push or a series of gentle nudges; you are probably on the right track. Focus on getting it to grow just a little wider; just a little faster each day of your life and you should be good.

I wish you good luck.

Flashback five years back in time; it is a warm sunny afternoon; phase one of the project has been done and rolled out a couple of weeks ago. I find myself sitting in a meeting where ideas for version-two of the product are being thrown on a white board.

Something keeps biting me deep down inside.

The deployment script; which we said we will come back to later; stands quietly at the bottom of the things-to-do list.

No one seems to be talking about it.

We are moving to version-two; with an implicit; unspoken understanding that the deployment script can wait.

There is one simple fact that we are missing out on; the fact that when your team works on a software; what they are doing is really very similar to participating in a car race.

You race against stupidity; you race against time; you race against a whole lot of other things; but you do not forget the cardinal rule - which is that you do not accelerate on curves and steep turns.

You slow down.

The couple of days that follow a sprint push are usually these slow-down times.

You let your sprints settle down; let them soak; let them stabilize and let each sprint sit there without any new features for a couple of days.

With increase in velocity; no time to slow down and stabilize; all you are doing is moving towards what the folks at 37Signals would call half-assed-mediocrity with a lot of features. In their book; getting real; they explain:

Build half a product, not a half-ass product.

Beware of the "everything but the kitchen sink" approach to web app development. Throw in every decent idea that comes along and you'll just wind up with a half-assed version of your product. What you really want to do is build half a product that kicks ass.

Stick to what's truly essential. Good ideas can be tabled. Take whatever you think your product should be and cut it in half. Pare features down until you're left with only the most essential ones. Then do it again.

With Basecamp, we started with just the messages section. We knew that was the heart of the app so we ignored milestones, to-do lists, and other items for the time being. That let us base future decisions on real world usage instead of hunches.

Start off with a lean, smart app and let it gain traction. Then you can start to add to the solid foundation you've built.

With every product sprint that you roll out; give it some soak time to stabilize. Do the housekeeping tasks. Fix your broken windows; give your team time to move away from any diversions they may have taken and get on the right track again.

I wish you good luck.

Jim Collins in his book Good To Great describes the concept of Fox and The Hedgehog using one simple diagram.

Jim; in his book; explains the concept using the simple story by Isaiah Berlin who divided the world into two kinds of people; foxes and hedgehogs. Jim explains:

In his famous essay "The Hedgehog and the Fox," Isaiah Berlin divided the world into hedgehogs and foxes, based upon an ancient Greek parable: "The fox knows many things, but the hedgehog knows one big thing." The fox is a cunning creature, able to devise a myriad of complex strategies for sneak attacks upon the hedgehog. Day in and day out, the fox circles around the hedgehog's den, waiting for the perfect moment to pounce. Fast, sleek, beautiful, fleet of foot, and crafty - the fox looks like the sure winner. The hedgehog, on the other hand, is a dowdier creature, looking like a genetic mix-up between a porcupine and a small armadillo. He waddles along, going about his simple day, searching for lunch and taking care of his home.

The fox waits in cunning silence at the juncture in the trail. The hedgehog, minding his own business, wanders right into the path of the fox. "Aha, I've got you now!" thinks the fox. He leaps out, bounding across the ground, lightning fast. The little hedgehog, sensing danger, looks up and thinks, "Here we go again. Will he ever learn?" Rolling up into a perfect little ball, the hedgehog becomes a sphere of sharp spikes, pointing outward in all directions. The fox, bounding toward his prey, sees the hedgehog defense and calls off the attack. Retreating back to the forest, the fox begins to calculate a new line of attack. Each day, some version of this battle between the hedgehog and the fox takes place, and despite the greater cunning of the fox, the hedgehog always wins.

The Hedgehog concept by Jim; is designed to work for both organizations as well as individual careers. It involves answering three simple questions:

1. What are you deeply passionate about?
2. What drives your economic engine?
3. What you can be the best in the world at?

Once you have found answers to the three questions; Jim gently nudges people to involve themselves with doing things; where answers to all these three overlap. The thing where the three circles overlap for you; is the thing that you want to spend your life doing and this is what you want to become a hedgehog doing.

As superfluous and abstract as the concept might sound; Jim uses his own journey to finding a personal hedge hog to illustrate a practical example of how this concept can be put to work.

In a world where we have programmers who cannot program and teams that go around in the infinite loop of failure maybe; conscious thinking and reflection of our very own personal hedgehog is something that every programmer should be taught in software development schools around the globe.

Have you ever spent time to consciously think and reflect on what your very own personal hedgehog is?

If you answered no; now might be a good time to start thinking about it.

I wish you good luck.

An acquaintance from the real physical world; complements me on having a good 'management blog'.

I cringe.

To be honest; I cringe every time someone refers to what I do at work or on this blog as 'management'. The word 'manager' or as I like to call it - the m-word is the one word; that you; dear reader do not want to have anywhere in your secret title.

You might be okay with tolerating the m-word sitting quietly in a tiny little corner of your business card; but not on your secret title.

Steve Yegge; in his famous post on not-managing-programmers describes his frustration with the term 'management' and the whole idea of striving to become a 'manager'. He explains:

But I think the best managers don't want to manage: they want to lead. In fact most leaders probably don't think about it much, at least at first, because they're too busy leading: rushing headlong towards a goal and leading everyone around them in that direction, whether they're on the team or not. Leadership stems from having a clear vision, strong convictions, and enough drive and talent to get your ideas and goals across to a diverse group of people who can help you achieve them. If you have all that, you're close. Then you just need empathy so you don't work everyone to death. If you're a great leader, you can put the whip away; everyone will give you everything they've got.

Put in that light, management no longer seems so glamorous, does it? Ironically, "I want to be a manager" is just about the worst sentiment a would-be manager could possibly express, because the statement has absolutely nothing to do with leadership. A leader doesn't fixate on management, which is after all just a bureaucratic framework that attempts to simulate leadership through process and protocol. Great teams building great things don't worry about process. They just build whatever it is as fast as they can.

The more HR-oriented a tech organization becomes, with manager training and manager forms and manager evaluations and manager this and that, the harder it is for a real leader to get any work done. Often as not, the actual leaders in the organization (at all levels, from individual contributors up through senior VPs) tend to be very slightly unpopular with HR, because they're always bending the rules and not doing things strictly by the book.

The true leaders in an organization are seeing the world through a very different set of eyes: the eyes, almost, of someone reading a story unfolding, except they're the ones writing the story. They can see clear as day how the world should be different in some way, and they're doing whatever it takes to get from here to there. And they're enlisting all the help they can get along the way, because getting others on board with your ideas is one of the best ways to accomplish your goals. They'll align their own goals with yours if they agree with you strongly enough.

Great companies recognize that leadership is orthogonal to management, and that people can be highly influential leaders with or without direct reports. The management hierarchy isn't generally helping the leaders. If you're lucky enough to have truly great leaders in your org, the best thing you can do is get out of their way and let them lead.

Any time I hear someone say "I want to be a manager", I just want to smack them. But maybe it's just me. 

Unfortunately I cannot tell you that I have seen it all; but in the years of software development I have done and the countless companies I have consulted with or visited; if there is one thing I have seen; it is that the best managers in the teams are usually the one who do not talk about management.

In fact; the managers who manage developers the best are managers who do not manage developers at all. All they do is; hire the best; and then get the obstacles out their way.

The best of the managers I've worked with; often do not tend to use heavy words. They do not tend to bitch about process; they do not tend to feel the yearning urge to manage others; or obsess over project plans. To be honest; the best of the managers I've worked with often do not even think or see themselves as managers; and they definitely do not use the m-word as frequently as their traditional-mediocre-counterparts. 

Remember; the best management is management that you cannot see; and the best managers are managers who do not need to manage people or things. True management is all using inspiration; dreams; story-telling or passion to mentor and align smart human beings towards remarkable goals which result in genuine win-win situations.

So; if you see me as a manager; or this blog as a management blog; maybe that's probably just because this blog is my journey away from the m-word and towards something more meaningful; and I may not be quite there yet.

The very fact that you see me as a manager probably tells me that I am not the best of the managers out there; but then: I'm learning.

Every single day of my life; and so should you.

Can we please stop using the m-word now and focus on common sense; empathy; cutting the crap; ethics and (as the title of this blog reads) simple 'logical thoughts'?

The best managers in the world do not use the m-word very frequently; they don't obsess over management either and neither should you.

Seriously.