Wednesday, September 07, 2005

We all need that approving nod

Be it at work, when you want to show your work to your collegues, your boss. Or when wearing a new shirt, you try to get others approval - just by judging their look, if not by asking them

Have you wondered why? Why is it that these little approvals are so important to us? One might wonder if it is because we are not self-sufficient as a person. That there are gaps in the personality - everyone's personality. The gaps that need filled by those approving nods, or pats on the back.

I think that to an extent is true. I would try to elaborate this by a hypothetical example.

We work as a team - we all do. There's this team working on a marketing project. Jess, a young, competent team member has been feeling lately, that her work is not appreciated that much. Actually she's feeling a bit down because of this.

One fine day, in the middle of a brainstroming session, Tim, one of her peers finds a good point in her arguments, and praises her idea. A couple other members agree too. Voila! they've made her day! She can feel herself quite high in her spirits. She spends the rest of the day light and charmed.

What exactly happened here? Jess got an approval from her peers - an approval of herself. Approval of her being. Her work. She might have been doing the same work all along. Just because an idea of her clicked among the peers, her downs have turned into ups.

What if the praise came from her boss, instead of the peers? There would be an added bonus (no, not in terms of money, at least not now :) ) - the praise is coming from someone superior to her. Someone she respects (more likely unwillingly, though). She knows that this impression she has made will bring her some benefit - sooner or later. So, along with an approval, she got an assurance that the approval will be recorded and can be encashed later.

See how much an approving nod can mean!

(to be contd.)

Tuesday, September 06, 2005

Planes of problems, planes of solutions

After 7 years of software-engineering experience, I wonder what kinds of problems do we solve. Is it technical problems - like how to write a web-page that can upload a picture to the server? Or, is it the business problem that the client wants his customers to save their searches?

If we look at the problems around us - and by this I mean all problems or questions we face in a given day - be it personal questions, like what color shirt would go best with these pants (believe me this is the best I can get with personal questions , lol), or problems related to spending, whether I should buy a large plasma-TV, or be content with the flat-Television I bought last month.

So, if we look at these questions, they can not only be categorized as financial, personal, psycological etc categories, they actually fall in a unique plane-of-abstraction. Abstraction: that is set by the context of the environment around that problem

I'll try to explain it by an example. One that we find at work. I am in software industry and we come across a lot of programming problems - like how to display all the customer's details in a single page in a user-friendly manner? This is a valid problem, and needs a special experience with the underlying programming language.

Also, you'll agree that designing the particular web-site is also a problem, and requires graphical-design experience and expertise with the underlying designing tools etc

Now think, is managing this development and design team a problem? Yes it is, and requires project management expertise. Now lets see this, there's also a problem of getting funding for this project - either through external customers, or internal departments, but this is a problem, and needs experience of handling funding. Running an IT department of a commpany and co-ordinating different software projects is also a problem. And so, is running the whole company, making sure the company yields profits at the end of the day..

Now, all this may sound trivial, and obvious details - probably too obvious to be noticed. The point i am trying to make is all these (and many more) are real-life problems that can be solved in a few simple steps:

a) Problem statement
b) Expected results
c) Statement of required Experience
d) Identification of people with required expertise, and
e) Execution!

Also, it may seem (and many managers love to this of this), as if these problems are different 'levels'. Managing a team is a higher-level problem than operations. Funding is a higher level than managing. Heading an IT deptt is at a higher level than all others, and so on...

Well, this may be one way of looking at things. But this certainly doesn't reflect the relative importance of these problem-planes. These are all equally important and critical planes of problems, and require all 5 steps from problem-statement to execution.

(more to come)