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.

After a gnawing reluctance deep down inside; I decide to approach Fred; my manager in my early days at Multiplitaxion Inc. The purpose of my visit to his office is to discuss possible problems our current development approach might have in the days to come.

For no particular reason; I am not very comfortable as I walk down the corridor towards Fred's office.

Something tells me deep down inside that sitting right across the table I am not going to see a manager with empathy - but an hourglass - constantly reminding me; through his body language; that the 30 minutes I have scheduled with him for this discussion are running out.

Fred; dear reader; like most traditional managers; is not really a busy man.

He is just playing busy.

Even as a young and budding engineer; I can sense it. Loud and clear.

Fred is popular in Multiplitaxion Inc for doing what this Harvard Business paper describes rather well:

Managers will tell you that the resource they lack most is time. If you watch them, you'll see them rushing from meeting to meeting, checking their e-mail constantly, fighting fires.

Managers think they are attending to important matters, but they're really just spinning their wheels.

For the past 10 years, the authors have studied the behavior of busy managers, and their findings should frighten you: Fully 90% of managers squander their time in all sorts of ineffective activities. A mere 10% of managers spend their time in a committed, purposeful, and reflective manner.

If you asked for 30 minutes of Fred's time; chances are that before giving you that time he would give you at-least one or two gentle reminders about how busy he is going to be with client meetings; meetings with the vice president or some other meeting you do not know anything about; when in reality every single one of us had serious questions on what it was that Fred really did or added to the organization or the team.

Where Fred and countless managers like him; who are busy trying to play busy; often go wrong is in getting their priorities right. Michael Lopp in his book Managing Humans describes this mistake rather articulately:

My first piece of advice to all new managers is "Schedule one-on-ones, keep them on the same day and time, and never cancel them."

With this mind, some of the trickiest transitions for me during the day are when these one-one show up. I'm deep in some problem, writing a specification, answering a critical email, and this person walks in my office and they want to talk about I don’t know what... I’m working in the zone here, people.

In the brief second  I try to figure out some way to reschedule this meeting, I remind myself of a simple rule, "You will always learn something in your one-on-one."

When is your manager giving you a chance to tell him what's in your brain? I'm worried if your answer isn't "at a one-on-one" but I'm not panicking, yet. Maybe your manager is one of these organic types who likes to jump you in the hallway and gather relevant bits. Terrific.

Does he do it consistently or when he needs something? The former is great; the latter is a problem waiting to happen.

A few years and a few promotions later; Fred is gone out of my life. Things at Multiplitaxion Inc change for good. I find myself working with a couple of managers who are genuinely fun to work with. The hesitation that I once felt while walking into Fred's cubical is gone.

Suddenly I find myself starting phone calls to my managers with - "Good time?" or "Can we talk?" - and getting responses on the lines of - "sure" or "yeah" unlike the standard canned - 'I'm a little busy now' or 'I need to take a client call' - response.

If they are busy; they make it a point to callback and start a discussion around the topic I wanted to talk about.

As you grow in your professional life; every once in a while you come across a few small things that have a big impact on your work environment and how you feel about your job. Your manager not being busy playing the role of the busiest man on planet earth; is definitely one of those things that can be a major deciding factor on how you feel about your work environment or how valued you feel at your workplace.

Years later; today; when I see a young and budding engineer walk up to my desk; and ask me if I am busy - my standard response is a big fat "no" or "no; of course I am not busy". 

Let us be totally honest here; on a typical workday; I probably spend a good twenty percent of my work day not doing any real work and so do you. We are not busy. We just like to pretend we are.

If you work happen to be in the same office as me and want to a quick chat on programming; life or any problem where I might be able to help; just walk in and start talking --- I'm free.

Are you; my dear young and budding manager?

If you want to work with a team one of the first things you need to learn is how to be free when someone walks up to you seeking help.

Pretending to be busy all the time and placing yourself in unapproachable ivory towers of 'upper management' is not genuine leadership; plus it will not take you anywhere.

Seriously.

Now go try not sounding busy for a change; even if you really are extremely busy.

I wish you good luck.

In an interview; Fred sits there on the other side of the table and complains about his current organization not hiring an 'experienced architect' to guide him; which he believes; is the thing that his impacting his growth. Fred has been working in the business of building software for the last seven years and Fred; dear reader; is still looking for 'a real life mentor' in his very own office who can 'guide' him or as he puts it --- help him grow.

I cringe.

Fred's looking for a mentor in his very own organization or team is a recurring theme I have seen in many programmers working in countless organizations around the world. To be honest; I have also seen teams of programmers act like orphaned children when the architect they look up to decides to resign and move over to another organization.

The whole - 'we need someone senior and experienced to guide us' - stream of thought is a recurring theme which manifests itself in multiple forms within most typical stereotype development teams I have seen in my life.

I look at Fred; and then reflect into my very own life trying to find a single technology mentor who helped shape my career; who I may have worked with in the real physical world.

I think of names; ranging from Scott Hanselman; Karl Franklin; Richard Campbell; Scott Guthrie; Venkat Subramaniam and countless others on the technology front to Michael Lopp; Steve Yegge; Joel Spolsky; Scott Berkun; Jeff Atwood; Seth Godin; Malcolm Gladwell and countless others on the non-technical; project management or soft skill front. If you take the entire list into consideration; I probably have more than a couple of hundred mentors.

The funniest part; however; dear reader; is that I have never even met any of these individuals in my real life; and yet these names and countless others have contributed towards successful projects; genuine growth and even the promotions that I may have had in my professional life.

Where Fred is going fantastically and marvelously wrong is that instead of learning from the best out there;  Fred; dear reader; is desperately seeking someone in his very own office to train him and mentor him.

Now; if you work in a software development firm that is not a Google or a Microsoft; like it or not; chances are; that you are not going to bump into the best of the world alpha-geeks or rock-stars in any field or domain; in your very own office.

You dear reader; will have to look out for them; reach out to them; and learn from them.

The best part about living a world that is so very connected is that anyone who is remotely passionate about anything; is also equally passionate about sharing his thoughts; ideas; findings and the best part of his personality either through a book; recorded webcasts; podcasts; blogs or whatever system of communication he find appropriate; with the whole wide world.

The real question is; are you willing to listen; participate and learn; from absolute strangers; who are willing to share their experiences and findings with you. If you are reading this; dear reader; chances are; that is exactly what you are doing right now. By reading this blog and these words; you  are allowing me to share my experiences and insights with you and you dear reader; are learning with me.

Behind the small LCD screen that stares at you; is a network that connects you to the smartest; wildest; funniest; craziest; most innovative minds in the world. If you constantly participate in the discussions and interact with people here; chances are that you might bump into these stalwarts; sharing their pearls of wisdom; and you might genuinely pick up a pearl or two. Keep doing that for long enough and you will actually grow faster than you expected.

You can either do that; or you can crib; cry and bitch about your organization not hiring that 'senior experienced mentor' who will come into your life and show you the light.

The choice is really yours; but if you ask me; I would gently nudge you to use the network behind that little LCD screen in front of you and connect with people who have genuine stuff to teach you. They are all out there. They are more than happy to teach you through the content that they give out as well as the experiences that they share online. Go - read; watch; follow and learn from the best of the world.

I wish you good luck.