What do you want from your employer?

-- publishing another old draft. written at my career low. it always helps to pause, think and know what is it that will make things better for you.  --

Peace of mind :)
Someone asked me this question a couple of days back and I thought it makes sense to write something down about it

Being paid and not doing worth it isn't fun. If you are not running at your full potential its a lose-lose situation that needs to be fixed asap.
The *right* fix for this is mutual which means it needs efforts from both ends. So you as an employee would do your bit (that is in your interest) and your employer (could read manager) should provide the complimentary bit!

So the answer to "What do you want from your employer?" boils down to: Provide me with an environment (read manager/co's, work, compensation etc) that will make most of my potential.
So to say provide that 'complimentary bit' whenever you run into issues.

From the perspective of worker (read developer) in the software industry this boils down to:

1. Flat hierarchy (mostly in technical choices)
Everyone should have say but the best *known* solution should be chosen. Highlighting known since its pointless to keep saying this is not right because of blah blah.. and not suggest what is the right thing to do.
End of the day the "best choice" should ship and not the "best mans choice" :)

2. Fairness
You should get what you are worth. This includes appreciation, compensation and credit to work. In any competition it is unfair for the judge to have favourites. Similar principle applies to the manager.

3. Challenge
The work should be challenging. Otherwise you are not hitting the limits which is the best way to grow forward.

4. Change
One cannot do "a" thing every day and keep doing that. It is natural to want to do something different. While this may not make sense to do everyday but it should be possible to do this every once in a while

Need help? Help yourself

--publishing another old draft. times when instant messaging was new!--

Very often you have issues and often you have to seek help from a colleague or an expert in that field.
Quite a fraction of this (typically) "seeking help" thing happens in a rather informal way. Apart from the coffee tables and over the desk medium this includes "chat".
Call it the "informal formal written talk" (brevity: IFWT). This is extremely handy. And no wonder its getting more and more popular.

Chat takes the best of written and spoken worlds.
1. Saves time
2. Keeps record
3. Stays informal
4. Interactive

Unfortunately a of people mess this up.

Lets start with a very common scenario.

c: hi.. 04:50 am
s: tell me.. 05:00 am
c: you there? 05:10 am
s: yes! 05:15 am
c: hi 05:15 am
----- no response from s ----
----- c continues with his greetings ----

Lesson 1: Get to the point quickly
Though chat is a interactive thing.. people are tied up with other work so you have to be prepared for delays in responses.
Since the person you seek to has less idea of what you want so its your onus to move forward in the process. (at least in the beginning)

Another scenario.

c1: hello
c2: hi
c1: i am getting a segfault when i start the app
c2: ohk.. i know why this happens. run the xyz script. should be okay..
c1: theres no such script! the environment is f!@#ed!
--- follows a special invesitgation ---
c2: damn! i thought you were talking about application foo!

Lesson 2: Set the context
It is very important to set up the context for any issue. There's a lesser chance of being misinterpreted. In this case, c2 could have also avoided the situation by proactively asking. Which app, where etc. But I am going to stay focus here on how the seeker can get things right.

Lesson 3: Make no assumptionsAs far as possible try giving as much information as possible, and make know assumptions about your helpers knowledge on your specific setup. It doesn't hurt to repeat yourself. A wrong advice does!

Lesson 4: Be Grateful
Again, it is you who needs help. Be polite, use smileys, and always thank him for his time!

Lesson 5: Talk to the right person
Its a very good idea to start with telling the person why you are talking to him in the first place. Especially when you are talking to someone you don't interact very often. He should know where you are coming from and whether or not he is supposed to/able to address your issue.

Lesson 6: Be a good listenerThis is very important. You have to tell your issue and not your ideas about the solution. So its very important for you to get rid of any preconceived notions. Your ideas about the cause of the problem can mislead him into thinking in the same way as you. And essentially end up in the same seat.
Of course you will always find in slots to put in your views/opinions/experiments. Don't just throw it all at him at once!

Most of this is applicable for email communication as well. But the anti-patterns described are more common over chat.

Timing a standup

UPDATE: Publishing this old draft I found. Early thoughts on stand-ups. Over the years I've realised stand-ups are  evil and one of the worst forms of micro-managing a team. Will pen my current thoughts in detail soon!


Its very tricky to deal with developers or for the developer to deal with himself for that matter. Most software companies have this very casual work culture and no one likes to be micro managed. There are times when this becomes a pain to the product manager, and even the developer feels he is getting off track.

Status reports monthly, weekly or even daily are the usual resorts. But the more friendly version is the standup meeting. In a typical cube setup of a team, everyone stands up and takes turn on updating the rest of the team on his status. While this is an excellent idea the timing of this can go terribly wrong.

Until I did it myself when I was leading a team, these stand-ups used to happen early in the morning. One of the reason being the manager wanted everyone to be at desk early. A status would mean, what I did since we stood last and what I plan to do next.

The morning time has couple of issues
- still not everyone is in
- you can get away with fancy deadlines for EOD today
- what you worked on yesterday isn't fresh in your minds
- one tends to defer work till later in the night

The later in the day stand up OTOH
- gives a nice incentive to work hard and present it end of the day
- don't waste to much time during the day, for end of day you'd be asked a question

I just started with this, and so far its worked well. I'd write more on how this approach goes in coming times! And may be with more teams, if I am able to inspire.