Who do you work for?

Who’s your customer?

Typically you work for your customer. A person who pays in return for your services. Its extremely important to know who or which one of them is your customer.

That’s easy, isn’t it.. OK. A small quiz:

Q. If you’re a software engineer.. Who’s your customer?

a) Project Manager

b) Team/Tech Lead

c) Your CXO

d) The actual customer of the company that you work for..

The answer almost always is one of the top three options.. and never the fourth one. By the way, fourth option needs to be the right one.

If you’re a manager, ask your folks this simple question and try it out.. Who do you work for? If you have atleast 50% of your folks say the name of the customer, you’re running a unique firm, most  probably a successful one too..

Minimizing the gap

The crux of the argument is that, its extremely essential that the execution team is well aware of the larger problem at hand. The actual problem that is being solved.

Most of our organizations have so many layers of hierarchy that the people who are executing have no contact whatsoever with the people who’re going to use their solution. No contact.. zip.. zero. Only time they probably meet the customer is some dinner some day.

This mode only guarantees mediocre solutions.. and yes, mediocre companies. The ones which depend on ignorance and mundaneness.. rather than enlightenment and innovation. Ones where developers are props (or famously known as ‘resources’) whose job is to stare at the monitor and tap the keyboard.

Developers are much more than that. Developers are problem solvers. They need to be treated that way.

In most cases that I’ve seen..

accessibility to clients/customer


the quality of the solution,

morale of the team and

overall comfort level of the customer.

As a developer, try to get close to the actual real problem at hand and contribute to the overall solution. As a head of organization, try to encourage your folks to engage at a higher level.

It benefits all the parties.. the developer, the organization and most importantly the customer.

Don’t just sit there..

This post is for programmers and managers who believe that spending more time on the project (in the office) is directly proportional to productivity of the programmer.  Ok.. I’ll break a secret here.. “IT’S NOT”. Obviously you need to be in front of a computer to type, but the similarity with programming just ends there.

Here are few misconceptions by managers:

1. A programmer can produce more lines of code if he’s working on the project.

Probably true (if he’s programming at all). But more lines of code IS NOT necessarily what software needs. There are many other metrics which define productivity and ‘lines of code’ doesn’t really feature there. In fact its the other way around.

2. Programmer is available for status updates and meetings.

If one requires programmers to be around just for this reason, there are better ways to do it. Read about Scrum, offline status updates, etc. One argument is discussing technical issues with other programmers. That is true but can be done without extended hours too.

3. One is more committed to success of the project.

This one is completely WRONG. There are many factors that determine the success of project. Project execution, Team bonding, Effective communication… Spending time is not. A programmer can be doing lot of things right, with a long term view.. producing readable and highly maintainable code.

Ok. So what should programmers do with their time?

Utilize portion of your working time honing your skills and updating on getting more productive. Here are a few simple things you can do:

Productivity Tips for Programmers

Who do you have in your team?

[tweetmeme source=”snarayan” only_single=false]

Every now and then you come across a colleague who fits right into a stereotype. Let me try describing a few of them here..

The yes guy.

The guy never has a problem with anything. He’s at peace with everything in life.  There’s not a single negative bone in the guy.

Delivery is not assured though. Sometimes you wonder, does he really think before answering at all..

The no guy.

He’s an exact opposite of our “Yes Guy”. He almost always comes with a negative answer to a situation. Sometimes he himself doesn’t know why he’s objecting to a solution, but he objects nevertheless.

The reasons could range from wanting to be heard to absolute clueless. But he has to object.

The invisible guy.

The guy who’s never really around. He works at inhuman times. Doesn’t believe in discussing to bring about solutions.

Only reason he’s not fired is because he has a proven track-record of solving complex problems.

The innovator

The guy who pops up new ideas left, right and center. Anything conventional is just boring. He jumps around at anything new. Lets do the new library by that community, Lets move to the new version of the api.. Left to him, he’d be redesigning the solution every month with one of his new tools.

The problem guy.

“I once used this library and faced many issues.. I don’t seem to remember. But, it doesn’t work”. This is a typical statement from our Problem guy. He’s done it all and exposed them all. He knows problems in anything and everything that we use. Very handy at times, but really annoying otherwise.

The social guy.

The guy who can’t think beyond 140 chars. Always looking for things that he can put on his profile. For him, this is the augmented reality which he uses to build his social profile. You’d see him most of the times on his twitter or facebook account. Has more conversations there than within the team.

The lawyer.

The person who can debate on everything. He loves to talk. Loves to challenge the decisions. He doesn’t necessarily believe in his argument, but still goes about for the sake of it.

For him, the debate is more important than the solution itself. He thrives in discussions..

The Buzzword guy

Lets write a mobile app in functional language with a light-weight nosql db and deploy its data on the cloud”. Statements full of buzzwords are a signature of such people. He thrives on latest. Reads up any blogpost and tweet posted lately. Always upto date and keeps looking at newer buzzwords. Can’t construct a sentence without them.

We all play one of these roles interchangeably.. But frankly, this diversity is what a team is all about. If all were the same, it’d be pretty mundane