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.

In one of my earlier post; I talked about the infinite loop of failure and the infinite loop of non constructive criticism. Joel Spolsky in his post on Figuring-out-what-your-company-is-all-about; how he avoids these loops using a simple diagram.

In the post Joel describes how he started Fog Creek as a company that programmers would absolutely love to be at. He also has a series of posts; like this one for instance; which shows the amount of time; thought and effort that Fogcreek spends behind their employees and their happiness.

If you work for most body shops or software development firms out there; or you are a manager who worries a lot about optimum utilization of human resources; chances are that you; dear reader consider happy programmers dangerous.

Erik Forsberg explains the idea as he narrates his very own personal experience as a developer conference:

Lot's of people from different tech companies in Linkoping. Someone said that Scrum kept the programmers happy which would produce better code. That's probably true. Here comes the fun part - another person in the audience were worried that happy programmers would code things they thought were fun instead of the things they were supposed to do.

Hmm.. yeah, right. That's the way it works. Or maybe not! I'd say that the risk is much bigger that bored programmers spend their time working at things they shouldn't do.

I would really like to know where this person works, so I can avoid working there.

The whole model of hiring cheap programmer; squeezing them to their limits; and micro-managing them to get results leaves most companies out there hanging in the realms of safe mediocrity.

The folks at 37Signals take the concept of happiness and bake it right into their Ruby-On-Rails framework to make developers around the world 'happy'. David Heinemeier explains this concept while giving an interview at eweek. He explains:

The author of Ruby, Yukihiro Matsumoto, tells us that he set out to create a language that would "make programmers happy." Rails attempts to run with that noble and profound goal and bring it to the world of Web application development. Were optimizing for humans first, compilers and the frameworks second. Its been a constant search for how we could make the development process more in tune with what makes programmers happy.

Kathy Sierra dissects the whole concept of happiness and talks about spreading it to all levels within the organization; even in areas which are connected to programming or seriously technical. She explains:

Understanding the connection between happy users and happy developers (or happy anything-supporting-users) is a big step forward.

The HR folks have cared about happy employees for a long time, but the notion of "happy programmers" was always more about benefits, perks, or pay... now a lot more people are starting to care--and talk--about things like programming language, API, framework, methodology, etc.

The things that keep you in a flow state.

If you take all of what his post has talked about so far and compare it with what happens in most organizations out there; what you might realize is that; most organizations out there; actually work hard at building technology; processes; business models; marketing techniques; sales strategies; when all you need to do if you are an entrepreneur is:

1. Hire the best programmers; managers; marketing guys; or for that matter; any other kind that you recruit.
2. Get out of their way - stop micro-managing and interfering in their job. 
3. Figure out innovative ways to keep them happy.

If you can do just these three things and do them well; chances are; that you might have a very successful and even a very profitable organization in the long run. After all; happy programmers build remarkable products; and even more remarkable organizations. Happy marketers often sell better without lies.

Now; go and rethink your policies; your compensations; your projects; your technology and your processes. Are they fundamentally built to make the best of your employees feel 'connected' to your organization? Are they designed to spread happiness? If you answered with a 'no' - get rid of them - and build new ones which are designed keeping the fundamental idea of happiness in mind.

I wish you good luck.

This post is about all about doing some serious soul searching and reflecting on your professional self.

If you have spent more than a couple of years in the business of building software you probably know by now that designations mean nothing. Anyone who has read a couple of books on neuroscience or management will tell you that the first rule of self improvement is that you stop trying to improve on your weaknesses and you utilize your core competence to make them stronger and more effective.

Step one to this process of-course is knowing what your core competencies are; and in a world where we excessively turn to business cards to pass our judgments on human beings; finding out your core competencies or what you 'really' do; is hard. Michael Lopp describes this rather articulately in his book - Managing Humans. He explains:

What do you do? Seriously, on your business card there is a title. Say it out loud.

1. "Senior Manager of Engineering"
2. "Industrial Data Analyst"
3. "Human Factors Specialist"

Is that what you actually do? Try this: think about the last four hours of your job and give yourself a title. Mine would be "Senior Meeting Wrangler" or perhaps "Guy Who Listens." Last week it would’ve been "Whiteboard Operator."

When you graduated from college, when you got your first job in your chosen profession, did you think you’d be doing this? No. Whatever you thought you'd be doing when you looked forward to being an "Associate Software Engineer" is not what you ended up doing.

You'd think this title dissonance issue would be a problem. You'd think that the fact that what you thought you'd be doing has nothing to do with what you do would turn into angst, but it turns out, as long as everyone is clear what your secret title is . . . we're cool.

The basic idea; dear reader; like all good ideas; is a rather simple one. Pause every once in a while as you work and question what you are 'actually' doing. Compare what you are 'actually' doing with what you business card reads and you might realize that you have more than one; what Michael calls --- secret titles.

The more you do this the more likely you are to find more of your implicit or secret titles. Club these together and you might be able to figure out a general direction of your core competencies. What is really scary about this process however; is that when you do this; chances are really high that you might actually discover that your core competencies evolve over time and they often have nothing to do with what your 'official' business card reads.

When this happens most folks panic.

After all; when your business card reads 'development lead' and you suddenly have a realization that you are just a 'guy who listens' it is easy to shift to the shit-I-am-going-to-get-fired mode and focus more on your development capabilities rather than your listening capabilities. If that is what you have done in the past; I have two words for what you may have done:

Big mistake.

If you; dear reader; were to wake up one fine morning; and you were to discover that morning that your secret title has developed a strong tangent with your what your business card reads; I have one advice for you:

Don't Panic.

Sure; spend a little bit of time doing what your business card reads; but instead of trying to force yourself to move back to your 'official' designation; try sticking around with your secret title and see if you can get better on that front. Then as you get better at doing what-ever-it-is that your neurons are naturally meant to be doing give out gentle signals of your secret title to folks around you.

Chances are; that people around you might accept you for what you were naturally meant to be and might actually like you for it.

Remember; the sooner you find out your secret titles and their variance from your official designation; and the sooner everyone around you knows and accepts this variance the happier you will be as a professional.

I wish you good luck

If you are in the business of building software; every now and then; you will find yourself surrounded with moments when the sky-is-falling. Every now-and-then; you might also come across seriously kick-ass engineers who emerge as super heroes and save the day.

It is rather easy to identify and reward these super heroes of your organization and shower them with pats on their backs; salary hikes and promotions. What is hard; dear reader; is identifying and recognizing the silent programmers; who avoid the sky-is-falling moments or as Michael Lopp in his book; Managing Humans calls Malcolm events. He explains:

Avoiding Malcolm events is completely unsatisfying and here’s why: you know what failure sounds like, but success is silent. It’s when the release goes well. It’s when you don’t have to release an immediate update to your major release. Avoiding a Malcolm event is when you managed to predict the future and no one is going to believe you when you tell them what you did because nothing happened.

Management is the care and feeding of the invisible. You’re doing your best when it appears the least is happening. I love the thrill of the last month of a release as much as the next guy, but I suspect the reason we’re yelling at each other, working weekends, and feeling the depressing weight of compromise is because we’re surrounded by Malcolm events.

Nassim Nicholas Taleb in his  famous book - The Black Swan - explains the exact same problem of identifying the true silent heroes and rewarding them much more dramatically through his excellent story telling and though experiment:

Assume that a legislator with courage, influence, intellect, vision, and perseverance manages to enact a law that goes into universal effect and employment on September 10, 2001; it imposes the continuously locked bulletproof doors in every cockpit (at high costs to the struggling airlines)— just in case terrorists decide to use planes to attack the World Trade Center in New York City.

I know this is lunacy, but it is just a thought experiment (I am aware that there may be no such thing as a legislator with intellect, courage, vision, and perseverance; this is the point of the thought experiment). The legislation is not a popular measure among the airline personnel, as it complicates their lives. But it would certainly have prevented 9/11.

The person who imposed locks on cockpit doors gets no statues in public squares, not so much as a quick mention of his contribution in his obituary. "Joe Smith, who helped avoid the disaster of 9/11, died of complications of liver disease."

Seeing how superfluous his measure was, and how it squandered resources, the public, with great help from airline pilots, might well boot him out of office. Vox clamantis in deserto. He will retire depressed, with a great sense of failure. He will die with the impression of having done nothing useful. I wish I could go attend his funeral, but, reader, I can't find him.

And yet, recognition can be quite a pump. Believe me, even those who genuinely claim that they do not believe in recognition, and that they separate labor from the fruits of labor, actually get a serotonin kick from it. See how the silent hero is rewarded: even his own hormonal system will conspire to offer no reward.

As software managers; we tend to look for people who emerge out of nowhere; and turn complicated defeats into victory and save the day. We glorify them and shower them with praise, salary hikes and promotions.

What we often fail to take a note of; dear reader; is the silent catalyst who gracefully builds synergy in the team; the brilliant engineer who does excellent estimations; the manager who sedates the monkeys; the technical lead who pushes the idea of keeping the team size small; the kick-ass programmer who quietly fixes the first broken window or the young recruit who changes the culture of the organization without making a lot of noise about it.

It is tragic but true; when it comes to the world of software development; a smooth sailing successful project without any panic moments does not seem to grab management attention. Add elements of panic; late night programming; working weekends or a rescue operation of an almost failed project and suddenly you have everyone giving you all the attention you want.

An excellent oracle database administrator who worked at one of our client; who for the purposes of this post; we shall refer to as Multiplitaxion Inc; received very little recognition for all his efforts.

During a casual conversation I asked him what was the most heroic moment of his life. He smiled at me and gave a reply which was somewhere on the these lines: 'none. maybe I should have taken our website database offline one or twice and then everyone in the organization would know me as a person who saved the day by bringing it back up. Maybe I should do that every five or six months and then I would be really famous individual in this organization'.

As a manager; the next time you come across a sky-is-falling event; a hero emerges out of nowhere and saves the day; sure; reward the hero; but also do a constructive analysis of why the sky-started-falling in the first place. Look hard; and you might find surprisingly new reasons and causes for the sky-falling.

As far as your smooth sailing projects are concerned; where Jack is sitting in the little corner and pushing the culture of writing clean code that takes a little bit more time; before you treat him like the legislator from Taleb's Black Swan thought experiment; do some serious soul searching and try to estimate the number of panic moments Jack is saving your organization from.

Next time you see Jack; try giving him recognition and reward for what he is avoiding with his talent and hard hard work.

Recognize your true silent heroes; give them  the recognition for their work; and you; dear reader; would have taken your first step to genuine management.

I wish you good luck.

Fred is struggling to answer the basic Fizz Buzz questions. He is answering them averagely well and yet something about both; his handshake and his personality seems nervous and weak.

Half an hour into the interview Fred seems desperate. He is fumbling; lying and pushing hard to get to the right answer; his desperation to get selected clearly showing in every question he answers. Half way thought the interview I ask him a question which changes the course of the entire interview:

'Tell me three things that you find completely unacceptable in an organization. Three things or attributes that if we had; they would make you reject a job offer; even if we were to give you one'

Fred looks at me like I just dropped a dead rat on the table. He thinks hard; and yet he cannot seem to think of one thing that would make an organization not worth joining.

What Fred; like most programmers who cannot program; was doing dear reader; was applying for a job where the only criteria that would decide if he joins us; was the criteria of us selecting him. 

Put simply; he would join any organization that offered him a higher salary; and had an interview process; he could somehow manage to clear.

Most veteran builders; unlike Fred; realize that interviews are not a phenomenon where a interviewer sits on the other side of the table and asks difficult questions which have to be answered --- 'somehow'.

Most veteran builders around the world that I have worked with; and in particular interviewed; realize that the act of applying for a job; is almost like making friends or for that matter; even dating; where both parties involved have to mutually decide if a relationship would work out in the long run.

If you happen to take interviews dear reader; may I suggest; that besides asking technical questions; you also spend a few minutes driving the discussion towards finding out the level of interest the candidate genuinely has towards your organization:

1. What does he know about your organization?
2. How much time has he spent on your website and what does he like or not like about your website?
3. How many valid and interesting questions does he have about your organization?
4. How many valid and interesting question does he have about the work he would be doing?
5. Is he even interested in knowing or finding out about the culture of your organization and how he fits into  the whole picture?

And most importantly; does the candidate have preferences; opinions and a spine strong enough to understand; that of the many programming jobs out there not every job is meant to be 'his' dream job; or even the one that he accepts.

When hiring candidates; don't just look for people who meet your criteria. Hire candidates who themselves have strong criteria; other than salary; that they expect the companies they join; to meet.

Hire candidates who clear your interview with confidence and then have the confidence to turn the tables around and interview your organization.

Hire folks who understand that of the many job offers that they can get not every job is worth joining. Hire folks who take time to know your organization; then actively interview and hand pick your organization; much like your organization hand picks them.

I wish you good luck.