This classic hugely inspirational scene from Glengarry Glen Ross has been one of my most favorite when it comes to getting things done.

Having said that, I am not so sure that this is a scene young and budding software marketers or sales guys should be watching though.

Coming from a consulting background I have been a part of countless sales calls and meetings. After watching countless sales deals that fizz out, if there is one thing that I have learnt about selling stuff it is that, If you want to sell badly enough, you will sell badly. If you try hard selling, selling will become hard.

Recent discussions with someone at work reveled a fascinating story on selling his used car. This person had been thinking of selling his car for a long time.

Somewhere during this time, his friend lands up with a broken car and since this car is sitting unused in his garage, he decides to help his friend and let him use it for a dew days.

"A few days later, this friend of mine comes to me and makes me an offer for the car", this person explains. "I told him that German cars need a lot of maintenance after a few years and if he wants a cheaper used car, he should be going in for a Japanese car, but he kept insisting on wanting to buy my car".

"I guess the one thing I learnt about selling and the whole try before you buy model is that you have to have genuine interest in helping someone when you let him 'try' your product. You cannot be thinking about selling when you are helping.", the person concludes his learning from the story.

The point? If your 'try' part is focused on moving your customer to the 'buy' part you will almost never sell. If your 'try' part is focused on helping the customer and letting him discover for himself if he genuinely loves your product to come back to you and buy it, chances are that you won't sell to everyone, but chances are also high that you will hit a niche of people who will really "want" your product.

Don't try to sell to everyone. Don't try to sell anyhow. Don't try to sell all the time.

If the "Always be closing" model is not working for you, the best you can do is move to an "Always be helping" mindset and then when you see someone who genuinely wants your product, give them the line that is dotted and chances are, they will sign on it happily.

I wish you good luck.

When you are the kickass rock star alpha geek of your team churning out code by the minute and getting things done, you love being in the flow. Then slowly, as more and more people in your team realize you can help and as you accept one promotion after another, somewhere it becomes fairly obvious that if someone in your team is stuck he is supposed to walk up to your desk and cause an interruption often without asking if it is okay to interrupt.

The first few years of this 'helping mode' are fun. You are busy helping everyone. You don't really care if you are not churning out a lot of a real work yourself. Time moves on. Fast forward a couple of years. You have managed to stay deeply connected with code, but on an average you just find a couple of hours of non interrupted work in a day. There are days when the builder within you asks you the question: 'What did you do today?'.

You know the answer to the question instantly.

The answer freaks you out.

There are two knee jerk reactions possible in this scenario.

If you were the geek who always loved code, you are going to go back and assign the most complicated module to yourself, lock yourself in that cubical for days f@#king up your responsibilities as a manager and those emails from your clients are going to sit in your inbox unanswered.

If you are the guy who was never quite good at coding you are going to take it upon yourself to walk up to every developer you can find and ask them the status three times a day. You are going to answer every single email in your inbox and watch your experience as a developer go down the drain as you morph from a capable alpha geek to someone who just answers emails and talks.

Both of these knee jerk reactions are small steps towards big problems.

What you need to do is take a pause. Breathe. Let the question soak in. Reflect.

What did you really do today?

You helped Jack by taking his rather long winded function and using an API that would do the same work in half the lines of code. You researched the API. You tried a quick POC on it with Jack. Of course, it was his work but it was your job to keep him moving forward.

Then you spent time responding to emails and building a story around your product so that the clients don't just look at the data.

You picked a bug or two. Fixed those. Did a scrum. Thought about a couple of new features.

And in the process of these you answered about a dozen questions on a feature, on a decision that had to be made or a problem someone was facing. You have done enough by doing nothing concrete which you can sign off as your work.

If there is a geek within you, he is never going to see any of the above as real work so yes you do need a couple of hours a day when you are logged out where you work on keeping your sword sharp and churning out some real code.

Having said that, the sooner you get used to the idea that at some point of time in your life, you will have to stop adding items to the list of things you personally did, stop showing this list to your bosses and start spending a decently big part of your day mentoring, teaching and guiding others, even though this does not really qualify as 'real work' according to the geek that you still are, the better off you will be.

Go on. Strike a balance between teaching, inspiring and doing.

I wish you good luck.

Earlier last week we talked about the Thousandtyone youtube video channel. Last week another video on the series of Entity Framework videos has been uploaded to the channel. Going forward additional videos are expected to get uploaded and if you would like keep a track of all the topics of videos that are getting released here is a quick table of content that will get updated every time a new video is uploaded.

Going forward an additional RSS feed will also be added for the videos. The whole point of starting the video channel was collective learning. If there are any specifics topics you would want me to cover, feel free to view the list of upcoming videos, vote and add items to the list.

Looking forward to your opinions, ideas and suggestions.

Project Plans and Gantt Charts have floated around in office corridors since Project Managers have existed in the business of software development.

The thing with folks who run around with these documents and knock on your cubicle three times a day, is not they they are bad human beings.

If they could have helped the developer who is running late at meeting his dead-line they would.

But most of them stopped programming at the first opportunity they found.

Typically here is how a developer manager conversation that I often overhear runs:

Manager: "We are running really late. Do you know what is wrong? Why are we taking so much time?"

Developer: "Not sure. I mean it is pretty straight forward but this nested query keeps timing out for no particular reason. I mean this is a simple cursor that takes the data from a table, throws it in a temporary table and then filters out the data we do not need. We have done similar queries in the past and they all run just fine."

Manager: "How much more time do you think we will need?"

Developer: I'm not sure.

Manager: Can we try to do this by the weekend? Its really important.

Developer: Hmm... okay... I will try my best.

Manager: Thanks. I will go ahead and update the status report.

Can you see what is happening here?

First, none of the parties are at fault here. They are just speaking a different language. The developer is clearly seeking help. He wants someone to sit down and take a look at the nested query. The manager would have loved to help, but he cannot. As much as he would love to help, he knows as much about cursors and queries as the developer knows about the Gantt Charts.

Usually in these cases, the manager also misses an important queue: that the developer is seeking help.

The manager switches to the Gantt Chart mode and talks about how much more time the developer would need.

After a while the developer gets the rules of the game and he stops discussing technical issues with his manager. They try to talk the language of the Gantt Chart, except of course, there is only one problem: Developers suck at speaking that language, specially when it involves saying no.

A disconnect begins.

Very soon, the performance of a developer who was otherwise thriving, takes a steep hard nosedive.

The post is not about criticizing managers or developers. I also don't have a recipe for success here. The only advice I can leave you with, if you are managing a team of developers, is, look for slightest of signs when your developers need help and when you notice that they need help, help them. If you cannot help them because you are not technical enough don't hesitate walking up to anyone in the organization who can genuinely help and ask for it.

Until you do that, chances are, that the nested queries will not automatically speed up by the end of the week.

The story of NewsTilt and why the young startup nosedived its way into failure and eventually shut down sends a chill down your spine as you read it.

As you read the post which describes one of the founder's view of why the organization failed, you start reading between the lines and you start finding dark gaps which give you a glimpse into what the real reason for NewsTilt's failing might have been. Embedded between the lines of the posts you find chilling comments passed with an innocent, matter of fact tone which make them all the more scary. For example, Paul (one of the founders of News Tilt) explains:

Since we needed to build so quickly, as soon as we got some money we wanted to hire another technical person. Nathan had a friend he wanted to hire, who was exactly the kind of great programmer he could work well with. However, it took some convincing to get him to try working on a news website, and he wasn’t sure he’d stick with it. We were sure we’d be able to convince him to stay, and we even waited two weeks for him to move to work with us.

Unfortunately, we were never able to excite him about the project, and we quickly realized he was never going to be intrinsically motivated the way we need for a first employee. There was a point when I was over in Cambridge with Nathan and the other developer, and I noticed that the developer wasn’t working on a Sunday. Now, we aren’t the kind of people who think our employees owe us 90 hours a week, but startups need that kind of work ethic from very early employees–exactly the reason that intrinsic motivation is so important. If your first employee doesn’t love what you do, doesn’t wake up each morning dying to work on HIS product, you have likely chosen poorly, and that’s exactly what we did.

As you skim through the article you begin to understand that the problem with NewsTilt wasn't any of the reasons mentioned in the post. The problem with NewsTilt probably was the fact that the founder believed that by jumping into an unknown domain and hiring idiots who work ninety hours week can make you a shitload of money. Take for instance this quote from the post:

Somewhat surprisingly, the journalists we picked were too good. We made a big deal of only hiring the “best journalists”, something we spent a great deal of time getting right. We had a guy with a Pulitzer, one with an Emmy, and overall a great deal of talent writing for us [3].

In hindsight, this may have been a big mistake. The kind of writer we actually needed was one that was hungry to succeed. Someone who would write five pieces a day, and who wanted nothing more than to be a big-time journalist. We needed a young Perez Hilton or Michael Arrington, people who wrote for 18 hours a day in order to make their names.

Instead, we got journalists who were already successful in their day jobs, and who already had families and other commitments.

Not to mention of course that these journalists were working for free. If this post does one thing, it bring out NewsTilt as a company which expected everyone, their employees and their journalists, to sacrifice their personal life and give in eighteen hours a day behind an idea and a domain that the founders themselves did not know anything about.

Paul explains why his idea was great and that Google could have made it work:

Google could have made this work. I believe that if Google applied the same model they could probably succeed. They have the tech ability, they have the traffic, and they already have a massive news property. They also have have a big problem with whiny news organization, and an elegant solution would be to kill them off by enfranchising their journalists to be their own bosses.

Of course Google could have made it work. But then again, Google is okay with giving twenty percent personal time from their normal five day work weeks to their developers, leave aside expecting them to work Sundays. Besides, Google is also not pointing fingers at their developers for not working weekends when their products fail. Not to mention that most successful developers work less and say no to meaningless slogging.

Let's face it. NewsTilt probably failed because of a lousy founder who wanted people to stop having a life and work ninety hours a week for an idea that he himself did not know deeply.

The entire post runs into pages and by the time you are done with reading it you realize that Paul could have done a way better job with the post by just saying  "I fu@#ked up. I am sorry". It would have been way better than whining about the developer not working weekends and the journalists having families. But then again, saying "I fu@#ked up" is hard.

Besides, realizing how bad you are at something requires the same skills that you need to become good at that thing.

Paul as a founder has a terrible blind spot that most readers of that post can see rather easily.

Go on. Read the chilling story of NewsTilt and it's failure and as you read it be sure to read between the lines and learn exactly the kind of attitude you should avoid while leading an organization, startup, business or even your small team at work. That and when you make mistakes, stop pointing fingers at others and accept the fact that it was you who fu@#ked up. After all, it is always your fault. Seriously.

The topic of a recent discussion that I got into revolved around what made 37Signals, 37Signals to begin with.

Was it their life style?

Was it their methodology?

Was it the fact that they were small?

Was it their book, Getting Real?

The opinion that emerged out of the discussion was that the answer was none of these. What made 37Signal, 37Signals is that they contributed true value in the form of Ruby On Rails, then Basecamp and then truckload of other products.

Ideas are a dime a dozen. Anyone can start a blog and talk at length about how amazing product management should be done.

Of course, anyone does not include the millions of 501 programmers, who cannot even program or muster enough motivation to lurk at a blog or own a book on programming, leave aside writing one, but well, anyone with enough motivation, some basic writing skills and some imagination can talk about software development and do blog posts on wisdom gained from doing years of software development.

If you do not have years of experience in software development, you can talk about social media and pull numbers straight out of your ass and impress people. Or better still, you can just quote numbers others have pulled out of their ass and act smart and knowledgeable.

If even that does not do it for you, talking about Entrepreneurship and how you will run your company when you start it up might do the trick.

Preaching, is easy.

Don't get me wrong. Sharing of ideas and experiences is what this blog has been about since its inception and we need some inspiration and sharing of ideas from time to time. It keeps our creative spirits alive. But too much inspiration can be addictive.

When you find yourself taking shots of inspiration morning, afternoon and evening. When you find yourself seated in meetings about entrepreneurship once every week, you know that you are just talking. Participating in a discussion, even at a world wide scale is good but do too much of it and you get a little sick and tired of it. There are times, when after years of blogging, you look back at your blog and you question if the value that you have added is adequate.

Yes you contributed a few innovative ideas, you sparked a few interesting discussions and you rocked on Reddit a couple of times but are ideas, thoughts and discussions all you can contribute? What about real value? What about a real product? What about discussing real code?

Somewhere months ago I asked myself this question and started Code Persona, my little corner where I document my development experiences. The site of course did not take off primarily because of lack of content.

Within weeks of starting the website it was rather evident that I might be decently acceptable at writing code (who needs talent when you have intensity) my ADHD makes it nearly impossible for me to write technical posts on the web much like I find it difficult to be reading from a physical book all the time.

But recently the desire to add genuine, concrete, value has been driving me nuts. In short, I have done enough of preaching and while I love sharing ideas here, which I will continue to do as frequently as I have been doing, I also really want to get out there and discuss something concrete. Like, say, code for example.

Without going into specifics, lets just say that it was simple divine intervention, that prompted me to grab a microphone and headset that had been sitting on my desk only to get used occasionally for boring conference calls, to start recording a series of videos on Microsoft Entity Framework.

The thousandtyone youtube channel was born.

This is 'not' going to be about thoughts on management, this is not going to be about discussion on process and hopefully this is not going to be about countless arguments on what is right and what is wrong.

This is going to be the IDE and code. We start with a series of videos on Entity Framework and from there every week we will dive into anything and everything that seems interesting. I spend a good part of my day breathing, writing, reading, eating, drinking and thinking about code. It is high time I start contributing something through it.

Like I said, the first series of about five to six videos is going to begin with Entity Framework but from there, we are going to jump into anything that seems interesting. Object Orientation, Inversion of Control, Test Driven Development. If it seems interesting, we might end up doing a quick fifteen minute video on it. If the video does not cover everything that had to be said on the topic, expect the video to turn into a series of videos.

Also expect to see a video series on Getting Started With Programming. I know quite a few business analysts, testers and managers who can benefit from that. Besides, the real motive behind that series is going to be teaching my young eight year old nephew how to write code.

The YouTube format of fifteen minute videos works perfectly for someone with ADHD like me. Besides you can chose to skip the videos, rewind them if you do not understand them or play them at triple speed if you believe we are moving along too slow.

Long story short, here is the thousandtyone youtube channel. We are going to write code on the record mode, we are going to learn how to write better code, we are going to teach you how to write better code and we are going to do that rather often. Hopefully, every week.

Code Persona will get updated every time a video gets published on the channel so if you are subscribed to it, you should get notified every time a new video hits the thousandtyone youtube channel.

Basically, it's like this. I spent all these years talking about good programmers and good programming. Here is your opportunity to see me writing code and tell me how much I suck at it. You are not going to miss that opportunity, are you? #Grins.

Go ahead, hit the channel, take a look at the first video and subscribe to it if you are interested in being a part of it.

What is your role in your organization?

What are you responsible for?

I know you are confused about your existence in your organization.

I know your designation means nothing.

But if you are a kickass programmer these are probably not the things that bother you as much as random stupid unpredictability in your work life.

Lets jump into the depths of time and bring from the ages that have rolled behind, the gist of what pissed off the best of the programmers at Multiplitaxion Inc. It was movement. Unpredictable, completely irrational and sometimes hugely irritating movement.

As a programmer you spent months working on a project. Putting in sweat and blood on the project and getting attached to it, only to be told one fine morning that you are now going to have an idiotic moron leading the project and you are expected to report to him.

Then there were historic moments where some of the most kickass programmers walked into office only to find out that they were expected to move to a different project all together and start their knowledge transfer effective the very same day.

As programmers we spend multiple hours a day talking to the compiler, where we expect the same consistent, coherent results for the same code written over and over again. We look for systems even when we are connecting to other human beings. The best of your geeks are afraid of unpredictability specially the kind that has 'stupidity' written all over it.

As a manager it is your responsibility that you reduce the element of unpredictability that gets thrown in your team's way to a minimum and if there is unpredictability it is positive unpredictability that challenges them and helps them grow stronger neurons. If you cannot do that the least you can do is be open about the changes in your organization and have no secrets. Transmit information openly.

If you must move them to a different project, do you have a genuine cause for doing that? Are you explaining your thoughts and your rational to them before you move them or are you basically passing orders from the ivory towers of management?

It takes years of solid teamwork, multiple streaks of good luck and a lot of stars have to align before you become a part of a project that is awesome, that rocks and that has the potential of making a dent in the universe of a small group of people or an industry.

All it takes to ruin that is a couple of stupid random unpredictable decisions that you impose on your team without discussing things with them, without listening to them and without giving them a chance to react.

There are multiple awesome projects that might be running in your team right now. A couple of programmers are spending their night time to work on aspects of your project that might take your project to the next level. The real question is, are you going to listen or are you just going to take random decisions and move people around like pawns on a chessboard?

Choose wisely, because your choice ultimately decides the future of your team and your projects.

Back in the days at Multiplitaxion Inc, Fred tends to throw random ad-hoc work on our plates every time he sees us passing by the corridors of the office.

More often than once we find ourselves gathered in the cafeteria discussing what it is that Fred himself does.

Michael Lopp explains this rather articulately in his book, Managing Humans. He explains:

“What, exactly, do you do?”

Slack.
Jawed.
Amazement.

This question is coming from someone I trust. A trusted employee who has been working in my group at the startup for years. This guy always tells me the straight dope and now he’s asking me what I do with my day because he honestly does not know.

My first reaction to this question is the wrong one. I want to leap over the table, grab my friend by the shoulders, shake him, and yell, “While you were uselessly staring at that one bug this morning, I was keeping this organization moving, pal.” My second reaction is to take a deep breath, so I do.

This basic what-do-you-do disconnect between employees and managers is at the heart of why folks don’t trust their managers or find them to be evil.

But the real problem here isn't the fact that Fred is incapable of answering the what it is that you do here question.

The most evil of managers are not the ones who cannot answer that question. In fact, the stupidest of managers are also not the ones who do not have much work on any given day. Most developers are used to both these kinds. Add a little bit of empathy to their characters and these two kinds are not really all that dangerous after all.

In fact, they might be adding secret ingredients to your project and your organization, quietly and subtly.

These are not the kinds that typically do the most damage.

The ones who do the most damage to your project, work and your team are the ones who don't have any work and to add to that, don't have a life either.

This is the breed that goes around the office with a printout of a project plan, the breed that buzzes the development team three times a day, the breed that organizes meetings that run hours and the breed that pulls out the stupidest of ideas or features straight out of their ass and then insist that they get implemented even when no one really needs them.

So, if you are a manager, the next time you walk up to someone's desk with a project plan in your hand and ask him the status of his module for the third time in that day because you don't have any other meetings to attend, remember that while you might not have anything to do, others in your team might be busy doing some real work.

Don't have work?

The least you can do is stop inventing random work for others and get a life.

Find a video game, play Farmville, take your son out, spend some quality time with your family, go home and stop bothering your team. Consider working less, even if you think you are supposed to 'drive and manage' the team. Seriously.